How Brij Sends Retail, Marketplace & Offline Purchases to Meta via the Conversions API

Overview

Your customers buy everywhere: your own store, Amazon, big-box retail, local shops. Meta only sees the conversions that happen on your site through its pixel. Every purchase made through an unowned channel is invisible to Meta, so its algorithm optimizes and attributes against a fraction of the revenue your ads actually drive.

Brij closes that loop. A QR code on the package turns an unowned-channel purchase into a registered, first-party customer, and Brij forwards that purchase to Meta’s Conversions API (CAPI) in the exact shape Meta expects. The result is deterministic, brand-owned conversion signal: off-site purchases become matched, attributable events, and Meta optimizes against your whole business instead of just dot-com.

How it works at a glance

1. Scan — after purchasing, the customer scans the QR code printed on the product or packaging, or accesses the Brij-hosted flow through digital distribution channels like link-in-bio or ads.
2. Register — they submit a short registration on the Brij-hosted flow (email, purchase details), unlocking warranty and perks.
3. Attribute — Brij ingests the registration, transforms it into a Meta purchase event, and POSTs it to the Conversions API.

Worked example

Consider a headphone brand that sells through its own site, Amazon, and a national retail chain. A shopper buys a pair in-store at a retailer — no pixel, no on-site checkout, so the sale is invisible to the brand’s Meta account. At home, the shopper unboxes the product, scans the QR code to register for warranty, and submits their details. Brij matches the registration to the purchase and sends a Purchase event to Meta. A conversion Meta could never have seen becomes a matched, attributable event tied to the campaign that earned it.

What Brij collects

The registration flow is deliberately short — enough to satisfy Meta’s matching requirements without inflating drop-off. Every field maps to a Meta parameter.

Where present in the registration session, Brij also captures Meta's click identifiers (fbc/fbp). See Click IDs and event source below.

The pipeline

The moment the customer submits, Brij ingests the registration as a first-party event, which triggers an outbound, server-to-server workflow:

1. Ingest — the registration is written as a structured event on Brij’s servers.
2. Transform — Brij validates and normalizes each field, hashes the identifiers, and reshapes the record into Meta’s payload schema.
3. Send — Brij POSTs the event to the Conversions API endpoint for the brand’s dataset.

All normalization, SHA-256 hashing, and payload shaping happen server-side at Brij before the request leaves. Because the call is server-to-server rather than browser-based, event delivery is more reliable and complete than browser pixels alone.

The payload

Brij sends events to POST https://graph.facebook.com/v{version}/{dataset_id}/events. Each request carries one or more events across three groups of parameters.

Event parameters

User data — matching

Sent SHA-256 hashed unless noted.

Custom data

Example request body

{
  "data": [
    {
      "event_name": "Purchase",
      "event_time": 1751808600,
      "event_id": "brij_reg_9f2a1c7e4b",
      "action_source": "physical_store",
      "user_data": {
        "em": ["e7c2f1a0d4b98c5e2f6a1b3c7d9e0f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e"],
        "ph": ["3b9f7c204a1d55e0c8f2a6b4d1e9c073a5f8b2d6c4e0a1f3b7d9c2e5a0f6b8c1"],
        "fn": ["a1d477ab0c2e9f13b6d8025a4c7e1f90b3d5a8c2e6f0b4d7a9c1e3f5b8d0a2c4"],
        "ln": ["9c0241de6b8a3f157e2d049c6a1b8f30d5c7e9a2b4c6f8017a3d9e5b2c40f168"],
        "country": ["79ad0f2c1b6e4a90d3f857c2e0b9a146d8c3f5a7e1b02d4c6f9a8b3e5d7c0142"],
        "external_id": "brij_5f3c9a27",
        "fbc": "fb.1.1751804000.IwAR2xk9QaExample_fbclid_value",
        "fbp": "fb.1.1751804000.1093874655",
        "client_ip_address": "203.0.113.42",
        "client_user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 18_5 like Mac OS X) AppleWebKit/605.1.15"
      },
      "custom_data": {
        "currency": "USD",
        "value": "129.99",
        "order_id": "BRIJ-2026-0000123",
        "content_ids": ["SKU-HP-XT900-BLK"],
        "contents": [{ "id": "SKU-HP-XT900-BLK", "quantity": 1 }]
      }
    }
  ]
}

Normalization. Before hashing, Brij lowercases and trims email and names, formats phone numbers to E.164, and uses ISO country codes, so its digests align with Meta’s hashing of the same values. fbc, fbp, IP, and user agent are always sent raw.

Click IDs and event source

fbc and fbp

When a shopper reaches the Brij registration page after clicking a Meta ad, the landing URL carries an fbclid. Brij captures it and builds the fbc parameter in Meta’s format (fb.1.<timestamp>.<fbclid>), and reads the _fbp first-party cookie for fbp. Click identifiers are the highest-confidence way to tie a conversion to a specific ad click, so Brij persists them with the registration and includes them on the outbound event whenever present.

Website vs. offline events

Registration always happens on the web, but the purchase it represents may not. Brij sets action_source from the place of purchase: website for online orders, physical_store for in-store and other offline sales. This lets Meta treat retail conversions as genuine offline events and apply them across both on-site and in-store optimization.

Routing to multiple datasets

Brands often run more than one pixel/dataset — by region, business unit, or sub-brand. Brij addresses each event to the correct dataset and can segment which events go where, so conversion signal lands in the account that owns the campaign rather than in a single catch-all.

Hashing and matching

Directly identifying fields (email, phone, name, and location) are hashed with SHA-256 before they leave Brij. Certain technical fields that Meta's Conversions API requires in unhashed form (the fbc and fbp identifiers, IP address, and browser user agent) are sent as received, as shown in the payload tables above. Meta hashes its own user graph with the same algorithm and compares digests; when they align, the purchase is tied to that user and any ad they saw or clicked. Because Brij sends a broad set of identifiers on every event, Meta has the maximum surface to make a confident match. Hashing is a security measure that protects data in transit and at rest; hashed identifiers remain personal information under U.S. privacy laws. The brand keeps the underlying first-party record.

Attribution and deduplication

Once matched, Meta credits the purchase to the campaign that earned it, using the attribution windows configured in Ads Manager (Meta’s defaults are 7-day click and 1-day view). Because every event carries a stable event_id, any overlap with a pixel event of the same name collapses to a single conversion — no double counting.

Outcome

Every Amazon, retail, and local-shop purchase Brij captures becomes a real, attributable conversion inside Meta. Optimization trains on the full set of conversions your ads drive, attribution reflects total sales rather than the dot-com slice, and the customer record stays owned by the brand.

Security and compliance

Directly identifying fields are SHA-256 hashed server-side before transmission; unhashed fields are limited to those the Conversions API requires. Brij maintains a SOC 2 Type I attestation and a privacy program designed to support brands' obligations under U.S. state privacy laws. The customer data underlying every event remains brand-owned. Brij's specific commitments are set out in its Data Processing Agreement.