Architecting a Unified B2B Lead Engine: Kotlin Multiplatform, Meta CAPI, Google Ads VBB & ERPNext in a DPDP-Native Framework (2026)

The Core Challenge: The Disjointed B2B Customer Journey in 2026

For years, B2B digital marketing has operated on a fractured foundation. We generate leads on platforms like Meta and Google, dump them into a CRM or a spreadsheet, and hope the sales team follows up. This disjointed process creates three critical, value-destroying problems in the modern AI-driven advertising landscape.

The Signal Scarcity Problem in B2B Google Ads

Google’s AI-powered bidding strategies, particularly Value-Based Bidding (VBB) models like Target ROAS and Maximize Conversion Value, thrive on data. They need a consistent stream of high-quality conversion signals to optimize effectively. In B2B, where a "conversion" is often a low-volume, high-value event (e.g., a demo request), this data stream is more of a trickle. An account might generate only 15-20 leads a month. This "signal scarcity" forces algorithms to operate in a low-confidence state, leading to inefficient ad spend and an inability to differentiate a high-potential lead from a low-quality one at the auction level.

The Qualification Gap in Meta Lead Ads

Meta Lead Ads are incredibly effective at capturing top-of-funnel interest with minimal friction. However, the lead quality can be highly variable. Without a robust, immediate qualification process, sales teams waste cycles chasing unqualified prospects, and the Meta delivery algorithm receives no meaningful feedback on which user profiles translate into actual business opportunities. The default feedback is a "lead," but the business needs to provide feedback on "qualified leads" or "sales-accepted leads."

The DPDP Mandate: From Afterthought to Architectural Core

With the enforcement of India's Digital Personal Data Protection (DPDP) Act, 2023, data privacy is no longer a checkbox; it's an architectural requirement. Retrofitting compliance onto a leaky, fragmented lead pipeline is a technical and legal nightmare. A modern system must be "DPDP-native," managing explicit consent, enforcing purpose limitation, and ensuring data minimization from the very first touchpoint on an ad to the final entry in the ERP.

Architectural Blueprint: The Unified B2B Lead Engine

To solve these challenges, we propose a closed-loop, event-driven architecture that unifies ad platforms, a mobile sales tool, and your core ERP system. This engine turns your ERP into an active participant in your ad optimization strategy, all while respecting user privacy.

Component 1: Meta Lead Ads & Webhooks (The Entrypoint)

The journey begins here. A user submits a Meta Lead Ad form. Instead of a simple email notification, this action triggers a real-time webhook.

• Technology: Meta Graph API (Lead Ads Webhooks).
• Payload: Contains the lead's form data (name, email, phone, custom questions) and crucial ad metadata.
• DPDP Consideration: The ad's privacy policy and the form's consent checkbox must explicitly state the purpose of data collection: "to be contacted by our sales team for qualification and product demonstration." This consent is logged with the lead data.

Component 2: The Kotlin Multiplatform Sales App (The Qualification Hub)

The webhook doesn't just go to a CRM; its payload is processed and pushed as a new, unassigned lead to a custom-built mobile application for the sales/field team.

• Technology: Kotlin Multiplatform (KMP) for a single business logic codebase targeting both iOS and Android. This is crucial for enterprise teams with diverse device ecosystems. Jetpack Compose for Android UI, SwiftUI for iOS UI. Ktor for networking, SQLDelight for local database/offline-first capabilities.
• Functionality:
  1. Lead Triage: A sales manager sees a dashboard of new leads and assigns them to specific team members.
  2. Instant Notification: The assigned salesperson receives a push notification.
  3. Structured Qualification: The app presents a standardized qualification form (e.g., BANT - Budget, Authority, Need, Timeline). The salesperson calls the lead and fills this out directly in the app.
  4. Offline-First: Using SQLDelight, the salesperson can qualify leads even in low-connectivity areas. The data syncs back once a connection is re-established.
• DPDP Consideration: Access is role-based. A salesperson only sees the data for leads assigned to them (Data Minimization). The app enforces that only data necessary for qualification is handled.

Component 3: ERPNext as the Single Source of Truth (The Value Core)

Once a lead is qualified in the KMP app, the data is pushed via a secure API to your ERPNext instance.

• Technology: ERPNext REST API.
• Data Model: The lead is created or updated in ERPNext. Custom fields are added to the "Lead" or "Opportunity" DocType to store:
  • Lead Source: "Meta Lead Ad"
  • Campaign ID, Ad Set ID, Ad ID
  • Qualification Status: (e.g., 'New', 'Contacted', 'Qualified', 'Unqualified')
  • Qualification Score: A numerical score based on the BANT assessment.
  • Estimated Deal Value: A monetary value assigned by the salesperson.
  • gclid (for Google Ads leads, captured via a hidden field on a corresponding landing page).
• Role: ERPNext is no longer a passive repository. It is now the SSoT that holds the ground-truth value of each lead.

Component 4: The Data Pipeline (Kafka/EventBridge for Asynchronous Processing)

The "save" event in ERPNext (when a lead's status changes to 'Qualified') triggers a message to a data pipeline. This decouples the ERP from the ad platform APIs, making the system more resilient and scalable.

• Technology: AWS EventBridge or Apache Kafka.
• Event-Driven: ERPNext emits an event like lead.qualified. The event payload contains all the necessary data for the conversion APIs (gclid, hashed PII, event_time, conversion_value).

Component 5: Closing the Loop: Meta CAPI & Google Ads Offline Conversions

A serverless function (e.g., AWS Lambda) subscribes to the lead.qualified event from the pipeline. This function is responsible for formatting and sending the data back to the ad platforms.

• For Meta: The Lambda function sends a QualifiedLead custom conversion event via the Meta Conversions API (CAPI). It includes hashed user data (email, phone) for matching, the event timestamp, and custom data like the qualification score.
• For Google: The Lambda function sends the gclid, conversion_time, and conversion_value (the estimated deal value) to the Google Ads API for Offline Conversion Import. This is the critical step for enabling VBB.

Deep Dive: The DPDP-Native Data Flow

Compliance isn't a feature; it's the foundation. Here’s how DPDP principles are woven into the architecture.

Consent Orchestration: From Ad Form to App

The initial consent text on the Meta Lead Ad form is paramount. A Fiduciary (your company) must clearly state the purpose. When the lead data enters the KMP app, this consent flag is attached. If a user withdraws consent (a right under DPDP), an API call can trigger a data erasure or anonymization process that propagates from the ERP backwards.

Purpose Limitation and Data Minimization in the Sales App

The KMP app is designed to strictly limit data access and use. The salesperson's interface only exposes the information required to make the call and fill the qualification form. They cannot export bulk lists or view data for leads not assigned to them. The purpose is "qualification," and the app's functionality is restricted to serving only that purpose.

Secure Data Transfer and Storage in ERPNext

All data in transit (from webhook to KMP app, from KMP app to ERPNext) must use TLS 1.2+. Data at rest within ERPNext should be encrypted. ERPNext’s robust permission management system is configured to ensure only authorized personnel can access sensitive lead data.

Anonymization and Hashing for Ad Platform Feedback

Critically, raw PII (like email or phone number) is never sent back to the ad platforms in cleartext.

• Meta CAPI: Requires SHA-256 hashing for all user_data fields. Our Lambda function performs this hashing before sending the payload.
• Google Ads: The feedback loop relies on the gclid, a unique click identifier. No PII is required, which is ideal from a privacy perspective. We are sending back the value of a click, not the user's identity.

Technical Implementation Walkthrough

Setting Up Meta Lead Ads Webhooks

1. In your Meta Business Manager, navigate to the Webhooks section for your Page.
2. Subscribe to the leadgen object.
3. Provide a secure callback URL pointing to an API gateway that triggers a serverless function to process the incoming lead.
4. Implement the verification request handshake.
5. Your function should parse the lead data and create a new lead entry for the KMP app.

Building the Kotlin Multiplatform App: Key Considerations

• Shared Logic: The core business logic—data models for leads, API clients (using Ktor) for communicating with your backend, and the database logic (using SQLDelight)—is written once in the commonMain module.
• Native UI: Use Jetpack Compose for the Android UI and SwiftUI for the iOS UI. This provides the best user experience and platform integration. The shared ViewModel/Presenter layer provides the state for these native UIs.
• Offline Sync: Implement a repository pattern that first writes to the local SQLDelight database. A separate synchronization service attempts to push queued changes to the remote ERPNext API when network connectivity is available.

Structuring Payloads for Google Ads API & Meta CAPI

Your final processing Lambda needs to construct precise payloads.

Example Payload for Google Ads Offline Conversion Import (JSON):

{
  "conversions": [
    {
      "gclid": "EAIaIQobChMI...",
      "conversionAction": "customers/1234567890/conversionActions/111222333",
      "conversionDateTime": "2026-08-15 14:30:00+05:30",
      "conversionValue": 50000.00,
      "currencyCode": "INR"
    }
  ]
}

Example Payload Snippet for Meta Conversions API (Server Event):

{
  "event_name": "QualifiedLead",
  "event_time": 1723712400,
  "user_data": {
    "em": ["a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3"],
    "ph": ["99c792b5d3cb1980f7b19452b4142f5349257252f8edc41b8a74e56994e432d6"]
  },
  "custom_data": {
    "value": 50000,
    "currency": "INR",
    "qualification_score": 85
  },
  "action_source": "system_generated"
}

This architecture is not just a theoretical model; it's a practical blueprint for building a resilient, high-performance, and compliant B2B marketing machine. By closing the loop between marketing spend and sales qualification, you provide the precise, high-value signals that AI bidding algorithms need to drive real business growth.

---

Frequently Asked Questions (FAQ)

Q1: Why choose Kotlin Multiplatform over React Native or Flutter for the sales app? For enterprise-grade applications, especially where performance and native feel are critical, KMP often has an edge. It allows for direct interoperability with native platform APIs without bridges, which can be a performance bottleneck. Given that many enterprise device management (MDM) solutions and security features are deeply integrated with the native OS, KMP provides a more robust foundation. Furthermore, for a team with existing Android (Kotlin) or iOS (Swift) talent, the learning curve is less steep.

Q2: How does this architecture handle the long B2B sales cycles? The architecture is designed for it. The initial conversion event sent back is "QualifiedLead." You can configure subsequent events to be sent at later stages of the sales funnel, directly from ERPNext. For example, when an "Opportunity" moves to "Proposal Sent" or "Deal Won," you can send new offline conversions with updated values. This provides Google's VBB algorithms with a multi-stage view of the lead's journey, further refining its predictions.

Q3: What is the role of a Customer Data Platform (CDP) in this architecture? A CDP can act as a sophisticated intermediary. Instead of a simple Lambda function, the event from ERPNext could be sent to a CDP like Segment or a custom-built one. The CDP can then enrich the data (e.g., with data from other sources) before forwarding it to the various ad platform APIs. This adds another layer of control, governance, and audience-building capabilities, but for a direct lead-to-conversion pipeline, it is not strictly necessary.

Q4: How does this architecture maintain data integrity, especially with offline-first capabilities? This is handled through a combination of strategies. The KMP app uses unique identifiers for each lead and qualification event. The synchronization logic should be idempotent, meaning if the same event is sent to the ERPNext API multiple times (e.g., due to network retries), it only gets processed once. Timestamps are crucial; the server (ERPNext) should always have the final say in resolving any data conflicts based on which update is newest.

---

Build Your Next-Generation B2B Engine

The gap between marketing action and business results is the most expensive problem in B2B. This unified, DPDP-native architecture closes that gap, transforming your ad spend from an expense into a direct investment in qualified pipeline. It's a complex system with many moving parts, requiring deep expertise in mobile development, cloud architecture, ERP customization, and ad platform APIs.

Induji Technologies specializes in architecting and building these exact types of high-performance, compliant systems. We can help you design and implement a unified B2B lead engine tailored to your specific sales process and technology stack.

Contact us today for a consultation and let's architect the future of your B2B growth.