What this sends to Meta (at a glance)

• Event name: Purchase
• Action source: Physical Store
• Purchase value: From the individual experience’s price value; or a fixed override for all events.
• Facebook cookies: fbc_ & fbp_ if they exist in customer’s browser
  • This helps link to ads in the scenario the user has a different email in Brij vs Meta.

When this sends to Meta

• When a consumer clicks submit on the email opt-in page of your selected experiences.
  • For now we only send the event to Meta at the “initiation” phase of a registration.
  • In the future we’ll add the option to choose if the event sends at initiation or submission (which is a fully completed registration w/ extra form details filled out if applicable)

1) Prerequisites

• Meta Pixel ID (for the destination pixel)
• Meta Access Token (CAPI)
• Alignment on which Brij experiences represent true NON-DTC purchases (e.g., product registrations)
  • Unselect non-purchase experiences (e.g., educational content, sweepstakes)
  • if you’re already sending Shopify purchases to Meta CAPI, unselect any experiences where a would register from a Shopify purchase.

2) Create the automation in Brij

• Go to Automations → New automation → choose Meta.
• Name it clearly (e.g., “Meta – Offline Purchase Registrations”).

3) Authentication Setup

• In Authentication, choose New authentication → Credentials.
• Paste the Access Token and Pixel ID the client provided.
• Name the auth (e.g., “Meta Auth”) → Save.

4) Select the right experience(s)

• On Select experiences, pick only purchase-like experiences (e.g., “AeroPress Registration”).
  • Unselect non-purchase experiences (e.g., educational content, sweepstakes)
  • if you’re already sending Shopify purchases to Meta CAPI, unselect any experiences where a would register from a Shopify purchase.
• Click Next.

5) Configure event details

• Event Name: Keep as purchase (default / pre-populated).
• Action Source: Keep as physical_store (default / pre-populated).

6) Configure purchase value

Choose one approach:

A) Pull from experiences (preferred)

• Leave Override = No and keep the override field blank
• Brij uses the experience’s value (ideal when each experience has a price set)

B) Use a fixed override (fallback)

• Set Override = Yes and enter a single amount (e.g., MSRP or AOV like 100)
• Use when some experiences lack values or you’re batching mixed experiences

We don’t know exact in-store prices; MSRP/AOV is a practical proxy unless there’s a reason to choose a different value.

7) Activate

• Click Save & Activate. The automation now begins sending CAPI events to the client’s pixel for all future experience registration initiations (email submitted).

8) QA & Verification (simple, reliable checks)

Open Meta Events Manager for the pixel and send a screenshot of:

• Go to Purchase events in Meta Events Manager
• View details → confirm Event Source = Physical Store

Sanity check: Compare counts vs. Brij automation runs for the same period. If automation shows ~100 runs and Events Manager shows ~100 physical-store purchases, you’re in good shape.

9) OPTIONAL: “BrijPurchase” for isolated QA (then revert)

• For short-term QA, you can set the event name to BrijPurchase to isolate our events in Events Manager.
• After validation, switch back to the standard Purchase name so you don’t need to rewire your ad sets/aggregations.
  • If you don’t switch to using the standard “purchase” event name, you will not see value from this integration.

10) Ongoing management

• Scope control: Revisit experience selection whenever you add new purchase-like experiences.
• Value hygiene: If product prices change or new SKUs lack values, update experience values or adjust the override.
• Mixed sources: If multiple offline sources feed the same pixel, document how you distinguish them in your runbook (dates, tags, or temporary event-name strategy during QA).

11) Troubleshooting

• No “Physical Store” events in Events Manager:
  • Ensure the automation in Brij is Active.
  • Re-check Access Token and Pixel ID.
  • Confirm purchase event and physical_store action source weren’t changed.
  • Confirm at least one eligible experience was registered since activation.
• Counts don’t line up:
  • Other offline sources may inflate numbers.
  • Some experiences may lack values—use an override or add values to experiences.
  • Ask Brij Engineer to confirm 200 responses and check for token expiry/rate limits.

Quick Checklist (for the operator)

• Have Pixel ID & Access Token from Meta
• Pick only purchase-like experiences (in Brij automation setup)
• Event = Purchase; Action source = Physical_Store
• Purchase value from experience or set override (MSRP)
• Verify in Events Manager (click purchase events in Meta and look for Physical Store count in Event Sources)
  • (If needed) short-term ‘Brij_Purchase’ test → revert to Meta approved ‘Purchase’ event naming

FAQ

• Do I need to be using Omni Ads for this to work?
  • No. There’s no requirement for Omni Ads, but if you’re using them, you get some additional benefits
• Does anything special need to be done to use Omni Ads?
  • Yes. You need to select it in the ad interface. Instructions here
• Is there a cost to this?
  • You must be on a Brij plan that includes Automations. Please reach out to support to discuss if you don’t have Automations.
• Can this be done on other ad channels like Google Ads?
  • Yes. For the time being, Brij supports Google Ads (and other platforms) through Google Tag Manager which is client side. We plan to add Google Ads to our server side integrations. This requires the “Custom Code” feature in your Brij plan, found in Settings if you have it enabled.
• How will the conversions be sent into Meta?
  • You can choose to send the purchase conversion into the standard “Purchase” event you are already using, or create an isolated event that you can name, like “BrijPurchase”. We strongly recommend sending the event into the same “Purchase” used for other events.
  • All events will also have “physical_store” as the action_source, so you can tell which purchases are from your online store and which are from Brij (non-DTC).
• Will this event impact my Event Match Quality (EMQ) scores?
  • No. Even if you send it into a standard “Purchase” event, conversions marked with action_source = “phsyical_store” shouldn’t impact EMQ scores.
• How can I see the conversions in Meta?
  • Click on the conversion, for example “Purchase” and look at the details. If physical store conversions are being sent you should see a breakdown per source
• What impact should we expect to see?
  • Depends on how many conversions you’ll be sending from Brij and how many conversions you send D2C. The larger the addition Brij makes, the more impact you’ll see.
  • To test, compare the period prior to Brij with a period where Brij is running and check your standard ad metrics like ROAS/CPM/Frequency/Etc…
• Can I filter some Brij registrations out, for example those that happen on our online store (D2C)?
  • Yes. This will require some thought in how experiences are setup. You can filter entire experiences for now, not certain registrations within the same experience.
  • One option is to ask the end customer to first chose where they bought (using a Router experience) and only send events for the experiences associated with non-D2C orders that are not already being sent to Meta. Ask Brij to demonstrate this if you need help setting up!
• Does Brij's data come strictly from scans of QR codes on product packaging, or does Brij have partnerships with Walmart/Target to tap into their 1P data?
  • Events and data sent to Meta only come from Brij experiences, using activity of your consumers. Brij does not get data directly from Target, Walmart or other retailers.
• How does a user's product purchase in-store (and subsequent QR scan) tie back to a specific campaign in Meta? How does Meta take the Brij data and tie it back to one campaign over another?
  • Click-ID match via ‎fbc / ‎fbp cookies: When the shopper scans the QR or visits a Brij experience, Brij captures the Meta click-ID cookies stored in their mobile browser and passes them to Meta. Meta uses these IDs to pinpoint the exact ad, ad set and campaign that generated the original click, giving you deterministic attribution for the purchase event.
  • Hashed identifiers as a fallback: If the shopper’s browser no longer holds ‎fbc or‎ fbp, Brij still sends hashed email /phone collected during registration. Meta matches those identifiers to the user’s ad-history and allocates credit to all campaigns the person interacted with, weighted by its standard attribution window.
  • Meta’s attribution engine: After matching, Meta’s attribution model (e.g., last-touch, data-driven, or 1-day/7-day click settings you choose) assigns the sale to one campaign over another and feeds that outcome back into ads reporting and budget optimization—so in-store QR scans can automatically influence your ROAS and learning phase just like online checkouts.