> ## Knowledge Base Index
> Fetch the complete knowledge base index at: https://docs.intractive.app/sitemap.xml
> Use this file to discover available pages before exploring further.
> Pure-Markdown content can be obtained by appending a '.md' suffix to the content URLs listed in the sitemap (without the trailing slash).

# Meta - Meta pixel and campaign tracking strategies

# Meta pixel and campaign tracking strategies
Sending story events to Meta does two things: it lets you build audiences from how people behaved in a story, and it lets Meta's algorithm learn who to show your ads to. Done well it makes targeting genuinely better. Done carelessly it teaches the algorithm the wrong lesson.
This article covers the setup, and then the more important part: which events to send and why.

| 💡 In one sentence: put the pixel in Tag Manager, send a small number of meaningful events, and optimise toward the most valuable event that happens often enough for Meta to learn from.

# Part 1 — Setting up the pixel
You'll need a **pixel ID** — a 15 or 16 digit number from Meta **Events Manager** → **Data sources**. If the client has never run a pixel, one has to be created there first, inside a business portfolio with an ad account attached.
## The base tag
1. In Tag Manager, **Tags** → **New** → **Custom HTML**
2. Paste Meta's pixel base code, with the client's pixel ID in it
3. Trigger: **Initialization - All Pages**
4. Advanced Settings → Tag firing options → **Once per page**
5. Name it `Meta - Pixel Base`

![](https://storage.crisp.chat/users/helpdesk/website/-/a/f/c/4/afc4fa0dc4a39800/meta-1_embngk.png)
![](https://storage.crisp.chat/users/helpdesk/website/-/a/f/c/4/afc4fa0dc4a39800/meta-2_8d3tf5.png)

## The event tags
One Custom HTML tag per event, each firing `fbq('trackCustom', ...)` or a standard event, using the triggers from the Analytics article.

⚠️ **Two things that make events vanish silently.**
**Fire order.** The base tag must run before any event tag calls it. Set **Advanced Settings → Tag sequencing → Fire a tag before this one** and choose `Meta - Pixel Base`. Also wrap each call in `if (typeof fbq === 'function') { ... }`. Without this the event simply never arrives, with no error anywhere.

**Quoting.** When you drop a variable into Custom HTML, Tag Manager pastes the raw value. A text value must be wrapped in quotes — `story_id: '{{DLV - storyId}}'`, not `story_id: {{DLV - storyId}}`. Unquoted, the code breaks and the event never fires.

And as with Analytics, put **Once per page** on any milestone event, or a single visitor will be counted as several conversions.
# Part 2 — Choosing which events to send
This is where the value is, and it's mostly one number.
## The 50-per-week rule
Meta's delivery algorithm needs roughly **50 conversions per ad set per week** to leave its learning phase. Below that, delivery stays unstable, cost per result is mostly noise, and the algorithm never really learns who to look for.

That inverts the obvious approach. The right event to optimise toward is **not the most valuable one — it's the most valuable one that happens at least \~50 times a week.**

Optimising toward story completions when a story completes fifteen times a week is worse than useless: you're giving Meta almost nothing to learn from, and paying for the privilege.

## The ladder
Pick the lowest rung that clears the volume threshold.
| Signal | Volume | Intent | Use it for |
| ---- | ---- | ---- | ---- |
| Story start | Highest | Low | Prospecting reach. |
| Reached the commitment point | Medium | Medium | **Usually the right optimisation event.** |
| Clicked out to the destination | Lower | High | Your real KPI, and the best seed for a lookalike audience |
| Story completed | Lowest | High | Reporting and retargeting. Rarely frequent enough to optimise on |

## Find the commitment point in your own data
Don't guess where the middle rung sits. Use the drop-off curve from Analytics: plot how many viewers reach block 1, 2, 3 and so on. The block where the curve **flattens** is the commitment point — past it, nearly everyone finishes. Fire your optimisation event there.

## Match the event model to the story's shape
This matters more than people expect, and getting it wrong produces confidently wrong numbers.
| Story shape | What to measure | Notes |
| ---- | ---- | ---- |
| **Linear** — blocks in sequence | Depth and progress. Start, halfway, complete all work as intended | The straightforward case. The triggers in the Analytics article apply as written |
| **Menu or hub** — pick a topic, return to a hub | *Breadth*, not depth: which topic they opened first, how many topics they explored, whether they reached the key screen | `progress` reaches 100 almost immediately in this shape, so a completion event here means very little. Use story variables to record which topics were opened instead |

| If you optimise a menu-style story toward "completion", you will teach Meta to find people who tap once and leave — because that's what completion means in that shape. Always check what progress actually does in the story you're measuring before you build conversions on it.

## Send a value, not just a count
The biggest quality lever after volume: include a `value` on your conversion event. That unlocks **value optimisation** and **value-based lookalikes**, so Meta optimises for who is worth more rather than who is merely cheapest to convert.

There's no revenue in most story campaigns, so use a score instead. Have the story compute a simple readiness score from its own answers — timeline, seniority, region, relevance — and send that as the value. Even a crude three-tier score (10 / 30 / 100) beats a flat count.

## Standard events versus custom events
Use Meta's **standard** events where they're an honest description of what happened: `ViewContent` for a story start, `Lead` for a genuine lead or application click, `CompleteRegistration` for a completed sign-up. Meta has cross-advertiser priors on these that custom events don't get.

Use **custom** events for anything without an honest standard equivalent, and turn them into a **Custom Conversion** in Events Manager so they can be optimised toward.

|| ⚠️ Don't send Purchase for something that isn't a purchase. It corrupts the model, breaks value reporting, and is not worth the short-term convenience.

# Part 3 — What to build in Meta
Once events arrive, the useful assets are:
* **Exclusions** — remove people who already converted from prospecting campaigns. No volume threshold, immediate saving, easiest win available.
* **Sequencing audiences** — people who reached the middle of the story but didn't click out. Show them a different creative. Also works at low volume.
* **Retargeting audiences** — everyone who reached a given point.
* **Lookalike audiences** — seeded from your highest-intent event. This is the big one, because it lets Meta find people who resemble genuine converters.
* **Custom Conversions** — needed to optimise toward a custom event at all.

| 💡 A working pixel is not the same as a usable audience. Meta wants roughly 1,000 people in a website audience before it will deliver against it reliably, and a lookalike needs a seed of a similar order. A test campaign can show everything firing correctly and still produce an audience Meta declines to use. Judge the setup on whether events arrive; judge the targeting only after real campaign volume.


# Part 4 — Closing the loop with your CRM or ATS
Story engagement is a proxy. The real outcome is usually further down the line: an application, a qualified lead, a hire. Meta will never see that from a pixel on the story page.

This is what the **Conversions API** is for. When the outcome happens in the client's CRM or applicant tracking system, send a server-side event to Meta containing the hashed email address and the click identifier stored earlier. Meta then optimises toward people who actually converted, not people who tapped through a story.

Story integrations already push data into HubSpot, Salesforce, Pipedrive, Recruitee, Carerix, and to any endpoint via webhook, n8n, Make or Zapier — which is where this loop gets built.

|| ⚠️ If you send both browser and server events for the same action, they must share an  event_id . Without it Meta counts both, so conversions look inflated, optimisation is trained on doubled data, and everything appears to be going well. This is the most expensive mistake in this article.

# Part 5 — Phasing a campaign
A brand-new pixel with no history, asked to optimise toward a rare event, will deliver badly and you'll wrongly conclude the approach doesn't work. Sequence it.
1. **Week 1** — Let ad set targeting do the filtering. Optimise on link clicks at most. Let the pixel accumulate history.
2. **Week 2** — Add exclusions and sequencing audiences. These pay off immediately and need no volume.
3. **Week 2 to 3** — Switch optimisation to the middle-rung event once it clears roughly 50 per ad set per week.
4. **Once you have \~1,000 qualifiers** — Build the value-based lookalike. This is where targeting quality really moves.
5. **Ongoing** — Feed CRM or ATS outcomes back through the Conversions API.

|| ⚠️ Beware of optimising for cheap traffic in low-cost markets. If a story deliberately filters people — by language, seniority or role — then optimising on a shallow, high-volume event will find you the cheapest possible clicks, which is precisely the audience the story is designed to filter out. In those campaigns, let targeting do the early filtering and move up the ladder sooner.

# Testing it
Meta has no equivalent of Tag Manager's Preview, so the loop is different.
1. **Meta Pixel Helper** (Chrome extension) — instant. Open a published story, tap through, and it lists each pixel call with its details as they fire. This is your real debugger.
2. **Events Manager → Test events** — select channel **Website**, then open the story *from that panel*. Only events launched from there appear in this tab; browsing to the story yourself will not show up here.
3. **Events Manager → Overview** — confirmation that Meta processed and kept the events. Allow up to 30 minutes, and check the date range includes today.

✅ **Quick checklist**
* Base tag on Initialization, event tags sequenced after it.
* Quote text variables inside Custom HTML.
* **Once per page** on every milestone event.
* Optimise on the most valuable event that clears \~50 per ad set per week.
* Check what `progress` means in *this* story before building conversions on it.
* Send a value, not just a count.
* Exclusions and sequencing first, lookalikes later.
* Share an `event_id` if you ever send both browser and server events.