Architecting a Data-Driven ONDC B2B Marketing Engine: Next.js 15, Headless ERP & Google Ads VBB

The ONDC Paradigm Shift for B2B Marketers

The Open Network for Digital Commerce (ONDC) is fundamentally re-architecting India's digital marketplace. For B2B enterprises, it's not just another sales channel; it's a decentralized protocol that promises unprecedented reach. However, this new paradigm shatters traditional digital marketing attribution models.

In a standard e-commerce flow, a JavaScript pixel fires on a "thank you" page, and the conversion is recorded. This is impossible in ONDC. A B2B transaction might be initiated on your portal (the Seller App), but the confirmation, negotiation, and final settlement happen across multiple network participants (Buyer App, Logistics, etc.) and can be asynchronous. The final transaction value, which could be a multi-lakh rupee deal, is only confirmed deep within your Enterprise Resource Planning (ERP) system, long after the user has left your website.

How do you prove the ROI of a Google Ads campaign that led to a complex B2B deal settled via the ONDC network?

The answer lies in shifting from measuring proxy metrics like clicks and leads to measuring true business value. This requires a sophisticated data pipeline that connects the initial ad click to the final, settled revenue in your ERP. This is the blueprint for building that engine, leveraging a modern stack: Next.js 15 for the frontend, a headless ERP for the backend, and Google Ads Value-Based Bidding (VBB) for intelligent campaign optimization.

Core Architectural Components: The Tech Stack Blueprint

To bridge the gap between ad spend and ONDC revenue, we need a resilient, event-driven architecture. Each component plays a critical, non-negotiable role in ensuring data fidelity and performance.

The Next.js 15 Frontend: The Interaction & Capture Layer

Your ONDC-enabled portal, whether it's a B2B catalog or a service marketplace, is the first point of contact. Next.js 15 provides the ideal toolkit for this layer.

• Server Actions for Secure Data Capture: When a potential buyer clicks a Google Ad, they land on your portal with a Google Click ID (GCLID) in the URL parameters. Instead of handling this client-side, we use Next.js 15 Server Actions. When the user fills out an inquiry form or initiates a quote request, the form submission is handled by a server-side function. This function securely reads the GCLID from the request cookies or hidden form fields and captures initial lead information. This prevents client-side manipulation and ensures the GCLID is safely on your server.
• Middleware for Identifier Persistence: Use Next.js Middleware to inspect incoming requests for gclid parameters. When found, store the value in a secure, server-side cookie. This ensures the GCLID persists as the user navigates across pages before they convert, making it available to any subsequent Server Action.
• Performance with PPR: B2B portals often have a mix of static content (product info) and dynamic data (pricing, inventory). Next.js 15’s Partial Prerendering (PPR) allows you to serve a static shell instantly while streaming in the dynamic components, providing an excellent user experience without sacrificing the ability to handle dynamic, user-specific data like the GCLID.

Headless ERP (e.g., ERPNext): The Single Source of Truth

A headless ERP is the non-negotiable core of this architecture. It decouples your core business logic (inventory, orders, pricing, accounting) from the frontend presentation layer. For our ONDC pipeline, ERPNext (or a similar API-first ERP) serves as the ultimate source of truth.

• API-First Integration: The Server Action on your Next.js app doesn't just capture data; it makes an API call to your headless ERP to create a new Lead or Quotation, associating the captured GCLID with this record.
• ONDC Order Processing: When an order is confirmed via the ONDC network, your ONDC adapter populates the transaction details in the ERP. This is where the deal is finalized, invoices are generated, and—most importantly—the actual transaction value is recorded. This could be the full contract value, a partial payment, or a recurring revenue figure.
• Webhook Emitters: The ERP must be configured to emit a webhook or event whenever a Sales Order or Sales Invoice linked to an ONDC transaction is finalized. This event is the trigger for our entire conversion pipeline. The payload must contain the original GCLID and the precise, finalized conversion_value.

The Data Pipeline: Connecting Clicks to Cash

This is the connective tissue of our system. An event-driven approach ensures scalability and decouples the components.

1. Initial Event (Next.js -> Message Queue): When a user submits a form, the Next.js Server Action, after creating the lead in the ERP, pushes a lightweight LEAD_CREATED event to a message queue like AWS SQS or a topic in Apache Kafka. This event contains the lead_id and the gclid. This step is optional for simpler setups but crucial for high-traffic systems to ensure resilience.
2. Conversion Event (ERP -> Data Ingestion): This is the most critical step. When the ONDC sale is confirmed in ERPNext, its webhook fires. This webhook should trigger a serverless function (e.g., AWS Lambda, Google Cloud Function).
3. Data Processing & Storage (Function -> Data Warehouse): The serverless function receives the webhook payload (gclid, order_id, conversion_value, timestamp, currency). It performs basic validation and then inserts this clean, structured data into a dedicated table in a data warehouse like Google BigQuery or Amazon Redshift. Storing it here, rather than sending it directly to Google Ads, creates a permanent, auditable record of your conversions—your "golden records."

Data Warehouse & Reverse ETL: Fuelling Google Ads VBB

Your data warehouse now contains the ground truth. The final step is to securely relay this information to Google Ads to train its VBB algorithms.

• Scheduled Uploads: A scheduled job (e.g., a cron job running a script or a Cloud Scheduler task) runs periodically (every 1-6 hours).
• Data Formatting: This job queries the data warehouse for new conversions since the last run. It formats each record according to the Google Ads API requirements for offline conversions: google_click_id, conversion_action_id, conversion_date_time, conversion_value, and currency_code.
• Secure API Call: The script then authenticates with the Google Ads API using OAuth2 and uploads the batch of conversions. Google will then process these, typically within a few hours, and attribute them back to the original campaigns, ad groups, and keywords.

The VBB Feedback Loop in Action: A Step-by-Step Walkthrough

Let's trace the entire journey of a single B2B conversion:

1. Click: A procurement manager searches "bulk industrial widgets supplier" on Google. They click your ad. The URL they land on is https://your-ondc-portal.com?gclid=XYZ123.
2. Capture: Your Next.js middleware saves XYZ123 to a server-side cookie. The manager requests a quote for 10,000 widgets. The Server Action reads the GCLID from the cookie and sends the quote request and GCLID to your headless ERP's API. A lead is created.
3. ONDC Transaction: Your sales team finalizes the deal for ₹5,00,000 via the ONDC protocol. The order is confirmed in ERPNext.
4. Trigger: The "On Submit" event for the Sales Invoice in ERPNext fires a webhook. The payload includes { "gclid": "XYZ123", "value": 500000.00, "currency": "INR", ... }.
5. Ingestion: An AWS Lambda function receives this payload, validates it, and inserts a new row into your ondc_conversions table in Google BigQuery.
6. Upload: At the top of the hour, a scheduled Cloud Function queries BigQuery for unprocessed conversions. It finds the ₹5 Lakh order and uploads it to the Google Ads API.
7. Optimization: Google Ads receives this high-value signal. Its VBB algorithm learns that the campaign which drove this click is extremely valuable. It automatically increases bids for similar audiences and search queries, optimizing your ad spend for maximum revenue, not just form fills.

Ensuring DPDP Compliance in Your ONDC Data Pipeline

Handling transaction and user data mandates strict adherence to the Digital Personal Data Protection (DPDP) Act, 2023. This architecture must be DPDP-native.

• Explicit Consent (Notice & Consent): On your Next.js 15 portal, before any data is captured, you must display a clear, concise notice explaining what data is being collected (including for marketing attribution) and for what purpose. Use a robust consent management platform (CMP) to capture and record the user's explicit consent.
• Data Minimization: The pipeline is designed for this. We are only sending the necessary, pseudonymized click identifier (GCLID) and non-personal transaction data (value, timestamp) to Google. We are not sending customer names, emails, or phone numbers to the ad platform.
• Purpose Limitation: The data collected (the GCLID) is used for the specific, legitimate purpose of measuring advertising effectiveness and optimizing campaigns, a purpose you must declare in your privacy notice.
• Secure Infrastructure: All data transmission must use TLS 1.2+. Data at rest in the ERP, message queue, and data warehouse must be encrypted. Access controls (IAM policies) should be strictly enforced so that only the necessary services can read or write to the conversion data tables.

Scaling and Future-Proofing the Architecture

This foundational architecture is built to scale and evolve.

• Predictive LTV (pLTV): Once you have a few months of conversion data in BigQuery, you can take VBB to the next level. Build a machine learning model that predicts the lifetime value of a customer based on their first transaction's characteristics (e.g., industry, product category, initial order size). Your data pipeline can then be modified to upload this predicted value to Google Ads, allowing the algorithm to optimize for long-term profitability, not just initial revenue.
• Multi-Channel Expansion: The "golden records" in your data warehouse are platform-agnostic. The same data can be formatted and sent to the Meta Conversions API (using the fbc click ID), LinkedIn Conversion API, and others. This creates a unified, multi-channel B2B attribution system.
• Handling Returns & Adjustments: ONDC includes protocols for returns and order adjustments. Your ERP should emit events for these as well (ORDER_RETURNED, INVOICE_ADJUSTED). Your pipeline can process these as conversion retractions or adjustments in Google Ads, ensuring your performance data remains accurate.

Frequently Asked Questions (FAQ)

Q1: How do I reliably capture GCLID in a Next.js 15 App Router environment?

Use Next.js Middleware. Create a middleware.ts file at the root of your src or app directory. In this file, check request.nextUrl.searchParams.get('gclid'). If it exists, set it in the response cookies: response.cookies.set('gclid', gclidValue, { httpOnly: true, secure: true }). Your Server Actions can then read this value directly from the cookies collection, ensuring it's available even if the user navigates away from the initial landing page.

Q2: What's the typical latency for this offline conversion upload, and does it affect VBB performance?

The latency is determined by your ERP event trigger and the frequency of your scheduled upload job. A typical setup uploads data every 1 to 4 hours. Google recommends uploading conversions within 24 hours for optimal VBB performance. The VBB algorithms are designed to work with this slight delay and will effectively use the data to adjust bids for future auctions.

Q3: Can I use a simpler stack without a data warehouse for a smaller business?

Yes, for a lower-volume setup, you can simplify. The ERP webhook can trigger a serverless function that directly calls the Google Ads API. However, this bypasses the benefits of having a permanent, auditable data store. You lose the ability to easily debug, re-run failed uploads, or expand to multi-channel reporting. We strongly recommend starting with a data warehouse like BigQuery, as its cost at a small scale is negligible and it future-proofs your architecture.

Q4: How does this architecture handle conversion adjustments or refunds processed via ONDC?

Your headless ERP should be configured to fire a webhook not just for new sales, but also for credit notes or return authorizations. This webhook triggers a separate serverless function that formats a "conversion adjustment" payload for the Google Ads API. You provide the order_id of the original transaction, and specify the adjustment_type as RETRACTION or RESTATEMENT (with a new value), ensuring your reported ROAS remains accurate.

Build Your High-Performance ONDC Marketing Engine with Induji Technologies

The transition to ONDC requires more than just a compliant Seller App; it demands a complete re-architecting of your marketing data infrastructure. Building this closed-loop system is a complex, high-stakes engineering challenge that blends modern web development, cloud architecture, and marketing technology.

The expert architects at Induji Technologies specialize in building these robust, compliant, and high-performance data pipelines. We understand the nuances of the ONDC protocol, the power of a modern Next.js stack, and the critical importance of feeding ad platforms with high-fidelity business data.

Don't let your ONDC marketing strategy run on guesswork. Request a quote today to build an engine that drives real, measurable business growth on India's new digital commerce network.