Architecting B2B Offline Conversion Pipelines with Kotlin Multiplatform for Meta & Google Ads

The Core Dilemma: Why Standard B2B Ad Tracking Fails in 2026

For B2B enterprises, advertising on platforms like Google and Meta is a paradox. The targeting capabilities are unparalleled, yet the measurement and optimization mechanisms seem purpose-built for high-volume B2C e-commerce. The core of the problem lies in signal scarcity.

Google's Smart Bidding and Meta's delivery algorithms are powerful machine learning models that thrive on data. They require a steady stream of conversion events—dozens, if not hundreds, per month per campaign—to learn who your ideal customer is and how to find more of them.

The Signal Scarcity Issue

A typical B2B company might generate 5-15 high-quality web leads per month from a specific campaign. From the algorithm's perspective, this is statistical noise. It's not enough data to confidently distinguish a future high-LTV customer from a tire-kicker. The result? The algorithm defaults to optimizing for the most obvious, top-of-funnel metric: the cheapest possible lead. This often leads to a high volume of low-quality MQLs that never progress through the sales funnel, wasting both marketing spend and sales team resources.

The Value Disconnect

The second critical failure is the disconnect between the initial conversion event (a form fill) and the actual business value. A "lead" is a signal of interest, but its value is minimal. The events that truly signal a prospect's potential and progress are:

• A demo being scheduled and completed.
• A key feature being used during a product trial.
• A proposal being requested and sent.
• A deal moving to the "Qualified" stage in your ERP or CRM.
• The first invoice being paid.

These high-value events happen "offline"—away from the browser and its tracking pixels. They occur within your internal systems and, crucially, within your enterprise mobile applications.

The Mobile App Blind Spot

If your business provides an enterprise mobile app for customers, partners, or field operations teams, it represents a goldmine of untapped conversion signals. User actions within these apps—adopting a new feature, completing a critical workflow, placing a replenishment order—are powerful indicators of engagement and future revenue. Without a strategy to connect this activity back to the initial ad click, you're flying blind, unable to prove or improve the ROI of your mobile-focused ad campaigns.

The Architectural Solution: A Unified Offline Conversion Pipeline

To solve this, we must re-architect the flow of data. We need to build a pipeline that captures these deep, high-value offline events and feeds them back to the ad platforms with the correct attribution identifiers. This is where a modern, unified stack featuring Kotlin Multiplatform (KMP) becomes a strategic advantage.

The proposed architecture stands on three pillars:

1. Unified Event Capture (Kotlin Multiplatform): A shared KMP module within your mobile app defines and captures business-critical events once for both iOS and Android.
2. Secure Server-Side Forwarding: A serverless backend endpoint that receives events, enriches them with attribution data, and securely forwards them to the ad platforms.
3. Ad Platform Integration (CAPI & Offline Imports): The final step of sending formatted data to the Meta Conversions API (CAPI) and Google Ads API.

Step-by-Step Implementation Blueprint

This is not a theoretical exercise. It's a practical, buildable system that can fundamentally change your B2B marketing effectiveness. Here's the technical blueprint.

Step 1: Defining High-Value Conversion Events in Your KMP Shared Module

The foundation of the entire system is clean, consistent event data. Kotlin Multiplatform is uniquely suited for this. In your shared KMP module, you can define a strict data contract for all analytics events.

Example: B2BConversionEvents.kt in the commonMain source set.

// In your shared KMP module (commonMain)
sealed class B2BConversionEvent(val eventName: String) {
    abstract fun toMap(): Map<String, Any>

    data class TrialFeatureUsed(
        val userId: String,
        val featureName: String,
        val trialTier: String
    ) : B2BConversionEvent("TrialFeatureUsed") {
        override fun toMap(): Map<String, Any> = mapOf(
            "user_id" to userId,
            "feature_name" to featureName,
            "trial_tier" to trialTier
        )
    }

    data class DemoCompleted(
        val userId: String,
        val salesRepId: String,
        val estimatedDealValue: Double
    ) : B2BConversionEvent("DemoCompleted") {
        override fun toMap(): Map<String, Any> = mapOf(
            "user_id" to userId,
            "sales_rep_id" to salesRepId,
            "estimated_deal_value" to estimatedDealValue
        )
    }
}

// Interface for your analytics tracker
interface EventTracker {
    fun logConversion(event: B2BConversionEvent)
}

This approach provides type safety and ensures that an event like DemoCompleted has the same name and parameters whether it's triggered from your Android or iOS app.

Step 2: Capturing and Persisting Attribution Identifiers

This is the most critical and often overlooked step. For the pipeline to work, you must capture the ad platform identifiers at the very first touchpoint and associate them with a user account.

• Google Click ID (gclid): When a user clicks a Google Ad, they land on your website with a gclid parameter in the URL. You must capture this parameter using JavaScript and include it in the hidden fields of your lead/signup form.
• Meta Click ID (_fbc) and Browser ID (_fbp): The Meta Pixel automatically stores these in first-party cookies. You should read these cookie values and submit them with your form.

When the user submits the form, these identifiers (gclid, _fbc, _fbp) must be saved in your backend database, tied directly to the newly created user's profile. They will be needed later.

Step 3: Building the Secure Ingestion Endpoint

Do not send conversion data directly from the mobile app to Google or Meta. This is insecure and unreliable. Instead, the app should send its events to your own secure backend endpoint. A serverless approach is ideal for this.

• Platform: AWS API Gateway with a Lambda authorizer and Lambda integration.
• Authentication: The mobile app must authenticate its requests, typically using a JWT (JSON Web Token) obtained at login. The API Gateway and Lambda authorizer validate this token before allowing the request to proceed.
• Payload: The app sends a JSON payload containing the event details (e.g., { "eventName": "DemoCompleted", "eventData": { ... } }).

Step 4: The Processing & Enrichment Layer

This is where the magic happens. The Lambda function triggered by the API Gateway orchestrates the entire process.

1. Receive & Validate: The Lambda receives the event payload from the app.
2. Fetch & Enrich: Using the userId from the event, it queries your user database (e.g., DynamoDB, PostgreSQL) to retrieve the persisted attribution identifiers (gclid, _fbc, _fbp) and personal identifiable information (PII) like email and phone number.
3. Hash PII: Never send raw PII. For Meta CAPI, you must SHA-256 hash the email, phone number, and other identifiers before including them in the API call. This is a critical step for privacy and compliance (e.g., DPDP Act).
4. Format Payloads: The function then constructs two separate payloads: one formatted for the Meta Conversions API and another for the Google Ads API.
5. Dispatch: It makes asynchronous API calls to both platforms.

Step 5: Sending Data to Meta Conversions API (CAPI)

The call to Meta's Graph API requires a carefully constructed payload. You will use the user_data object to send the hashed PII, which Meta uses for matching the server event to a user profile.

Pseudo-code for the Meta CAPI request:

// Inside your Lambda function
const payload = {
    "data": [{
        "event_name": "DemoCompleted",
        "event_time": Math.floor(Date.now() / 1000),
        "action_source": "app", // or 'system' for CRM events
        "user_data": {
            "em": "HASHED_EMAIL_SHA256",
            "ph": "HASHED_PHONE_SHA256",
            "fbc": "USER_FBC_COOKIE_VALUE",
            "fbp": "USER_FBP_COOKIE_VALUE"
        },
        "custom_data": {
            "value": 2500.00, // Dynamic value of the conversion
            "currency": "INR"
        }
    }],
    "access_token": "YOUR_PIXEL_ACCESS_TOKEN"
};
// Make POST request to https://graph.facebook.com/vXX.X/YOUR_PIXEL_ID/events

Step 6: Sending Data to Google Ads API (Offline Conversion Import)

For Google, the process is simpler if you have the gclid. You'll use the Google Ads API to upload a ClickConversion.

Pseudo-code for the Google Ads API request:

// Inside your Lambda function, using the Google Ads SDK
const clickConversion = {
    gclid: "USER_GCLID_FROM_DB",
    conversionAction: "customers/CUSTOMER_ID/conversionActions/ACTION_ID",
    conversionDateTime: "YYYY-MM-DD HH:MM:SS+ZZ:ZZ",
    conversionValue: 2500.00,
    currencyCode: "INR"
};
// Use the ConversionUploadService to upload the conversion.

The Business Impact: From ROAS to Predictive LTV

Implementing this architecture moves your ad strategy beyond simple lead generation.

• Effective Smart Bidding: You are now sending 10x or 100x more conversion signals to the ad platforms. More importantly, these are high-quality signals that correlate with revenue. This gives Smart Bidding strategies like Target ROAS (Return On Ad Spend) and Target CPA (Cost Per Acquisition) the data they need to work effectively for B2B.
• True ROI Measurement: You can assign dynamic, realistic monetary values to each offline event. A DemoCompleted might be worth ₹5,000 in potential LTV, while a DealWon event is worth the actual contract value. The ad platforms will then optimize for users likely to generate the highest total value, not just the cheapest click.
• Closed-Loop Reporting: This architecture finally closes the loop between marketing spend and sales outcomes, providing a clear, data-driven view of what's working and what isn't.

Frequently Asked Questions (FAQ)

Q1: Why use Kotlin Multiplatform instead of native Swift/Kotlin for event tracking? While you can build this pipeline with fully native apps, KMP offers a significant advantage in consistency and efficiency. By defining your B2BConversionEvent classes and tracking logic in a single shared codebase, you eliminate the risk of the iOS and Android teams implementing events differently, which could corrupt your data. It's a "define once, track everywhere" approach that reduces bugs and engineering overhead.

Q2: What if we don't have a mobile app? Can this architecture still work? Absolutely. The principles are the same. Instead of a mobile app, the event sources would be your web application's backend (e.g., when a user completes an onboarding step) or your CRM/ERP. You can use webhooks from your CRM (like Salesforce or HubSpot) to trigger the same processing Lambda function whenever a deal stage changes, feeding those events back to the ad platforms.

Q3: How do we capture the gclid if the user signs up days after clicking the ad? This is a classic attribution challenge. The best practice is to store the gclid in a first-party cookie on your website with a longer expiration date (e.g., 90 days). When the user eventually returns and signs up, your client-side script should check for the presence of this cookie and include its value in the signup form submission.

Q4: What is the minimum number of offline conversions needed per month for this to be effective? While there is no magic number, Google generally recommends at least 30-50 conversions per month for a campaign's Target CPA to perform optimally. With this pipeline, you can combine multiple types of offline events (e.g., 20 TrialFeatureUsed events + 10 DemoCompleted events + 5 ProposalSent events) to reach and exceed this threshold, providing a rich, diverse set of signals.

Q5: Can we use a Customer Data Platform (CDP) like Segment instead of building a custom pipeline? Yes, a CDP can simplify the "dispatch" part of this architecture. You would still need to implement the event capture in your KMP app and send the data to your backend for enrichment (adding gclid, hashing PII). From your backend, you would send the clean, enriched event to the CDP (e.g., via Segment's HTTP API), and the CDP would then handle the fan-out to Meta, Google, and other destinations. This can be a good option for companies that already have a CDP in their stack.

---

Unlock Your B2B Growth Potential

Building a robust, scalable, and compliant offline conversion pipeline is a complex engineering challenge that sits at the intersection of mobile development, cloud architecture, and marketing technology. Getting it right can provide a durable competitive advantage, dramatically improving the efficiency and ROI of your entire marketing budget.

The team at Induji Technologies specializes in architecting and implementing these sophisticated data pipelines. We combine deep expertise in Kotlin Multiplatform, serverless cloud infrastructure, and the intricacies of advertising APIs to build systems that drive real business results.

Ready to stop guessing and start optimizing for revenue?

Request a Quote Today and let our expert engineers design the B2B conversion architecture you need to win in 2026.