Omnichannel-first businesses rarely have a web-only customer journey. People discover products online, compare options, and still complete the purchase in-store or through offline touchpoints.
When campaigns optimize only for website purchases, part of performance can stay outside reporting and optimization – even though it is influenced by your ads.
This webinar covers how Meta Omnichannel Ads are designed to optimize for website and in-store outcomes in one Sales campaign, what to prepare before launch, and how to set up Conversions API for offline events in practice. You will also see a live setup walkthrough and learn the most common issues that affect readiness and data quality.
Speakers:
1. Omnichannel Ads deep dive
Learn what Meta Omnichannel Ads are, who they are best suited for, and what they unlock for omnichannel-first businesses.
2. Readiness plan and key requirements
Discover a practical rollout plan and the readiness prompts you may see, plus the most common issues that slow implementation.
3. Live demo – Conversions API for offline events
Watch a step-by-step walkthrough of setting up offline conversions and validating the setup.
4. Launch and monitor Omnichannel campaigns
Explore how to create the campaign in Ads Manager and what to monitor after launch.
5. Q&A session
Get answers to your setup, data quality, and rollout questions.
Click the button below to get the webinar presentation.
Meta Ads originally disabled omnichannel optimization for manual uploads on purpose. Meta is changing that now. The idea is to show the value of omnichannel ads first, and then use Stape to build an automated connection—so it’s no longer manual and less prone to human error or missed uploads.
I’d choose a CRM based on your business needs first. Most CRMs can trigger a webhook that sends data to sGTM for processing. For popular CRMs, I also have ready-made apps that simplify setup.
I validate it in Meta’s Dataset UI, and I also check the request and event logs in Stape Logs.
I’d start by reviewing your container configuration and your webhook handling. In most cases, duplicates come from the same tag being triggered multiple times, multiple listeners firing, or the webhook being processed more than once. Also, the workflow I showed is designed to receive one webhook, enrich it, and then route it to multiple destinations—so if Pipedrive sends multiple webhook hits for a single “WON” transition (because several fields/statuses update at once), sGTM will process each hit unless you add deduplication or tighten the trigger conditions. If you want, you can send directly to destinations, but that typically takes more time to set up and maintain.
I recommend sending all relevant data you have in your CRM. In general, the more usable data you send, the better Meta’s quality metrics tend to be.
In my view, Shopify’s native Meta integration is mostly a delivery method and focuses mainly on online events. It doesn’t fully cover omnichannel needs—especially physical-store purchases. That’s where I use Stape, because it helps connect and automate those offline signals.
Usually no. If your setup already captures identifiers like email, I can store that in the Enricher buffer and then automatically enrich later offline purchases when the CRM sends a matching identifier. In a server-side GTM setup, enrichment keys are structured so tags (including Meta) can pick them up without extra manual mapping in most cases.
If your CRM doesn’t store browser IDs like FBP/FBC, I store them somewhere else and then pull them later via an API or endpoint, if your stack supports it. For WhatsApp/offline-style flows, I prioritize strong match keys like email and phone, and add any other available attributes where appropriate. If I can retrieve browser IDs too, I still do it. The more match keys I send securely and compliantly, the better.
I focus on match quality inputs: a solid PII set plus two key identifiers—browser ID and click ID. IP address and user agent also matter, and I typically capture those automatically.
In practice, conversion location value rules are set at the campaign level. If I need different value rules, I usually separate this into different campaigns so each one can have its own logic.
I rely on a consistent event_id for deduplication. If multiple systems fire the same purchase, I often use the transaction ID as the event_id because it’s most likely shared across systems. I try not to rely on fallback matching alone—I prefer robust IDs wherever possible.
Faster is always better. As a rule of thumb, I try to keep the delay within ~3 days for the key conversion event, especially purchases. Once you get closer to a week, performance can become less consistent because the model gets less timely training data.
I start with email as the primary resolution key. Depending on the journey, FBC might still be available earlier in the flow, but the details of the implementation matter.
It’s central. The more high-quality customer data I can legally and appropriately send, the better platforms can match conversions back to users and campaigns.
No, Enricher doesn’t depend on the Facebook click ID for identity resolution. I use a hierarchy of identifiers, for example, email and other deterministic IDs, and treat click IDs/FBC as helpful additional signals when available. Server-side tracking is what I rely on to reduce the impact of browser limitations.
Comments