> ## 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 - Adding a Meta pixel without Tag Manager # Adding a Meta pixel without Tag Manager Every project has a **Footer scripts** field, which injects raw script tags at the end of the public page. That is enough to run a complete Meta pixel โ€” base code, story events, scoring, consent โ€” with no Tag Manager container at all. This article covers when that is the right call, and gives you a snippet that only needs four lines changed per client. | ๐Ÿ’ก In one sentence: paste one script into Footer scripts, change the pixel ID, and you get the same five events Tag Manager would send โ€” at the cost of debuggability and client self-service. # Which route to choose | Consideration | Tag Manager | Footer script | | ---- | ---- | ---- | | Time to first event | Slower โ€” the client must provision container access | Minutes, if you have admin on the project | | Who can change it later | The client's own marketers | Only an Intractive admin | | Debugging | Tag Assistant shows every tag and why it did or didn't fire | Browser console only | | Several destinations | Add a tag | Edit code | | Versioning and rollback | Built in | None | **Use Tag Manager** when the client wants to own their tracking, when Analytics is in scope too, or when the campaign will run long enough for someone to want changes. **Use the footer script** when the client has no container and no appetite to get one, when the campaign is short and the events are already agreed, or when you need something live this week. โš ๏ธ **Never run both at once.** If a project has Meta tags in Tag Manager *and* this script, every event is sent twice to the same pixel. There is no `event_id` on either, so Meta counts both as real. This was measured: a single story start produced two `ViewContent` events. Pick one route and remove the other. # The five events Every Intractive story sends the same five. Keeping the vocabulary fixed matters โ€” all our stories share one domain, and Meta budgets configurable events **per domain**, not per client. Inventing new event names per project burns a shared allowance and makes accounts inconsistent. | Event | Meta type | Fires on | What it's for | | ---- | ---- | ---- | ---- | | `ViewContent` | standard | Story start | Audience seed, and the denominator for every drop-off number | | `StoryHalfway` | custom | Reached 50% | Engagement. Tells you whether the ad or the story is the problem | | `StoryComplete` | custom | Reached 100% | Retargeting people who finished but didn't click | | `Lead` | standard | Outbound link click | **The conversion.** Optimise campaigns on this | | `QualifiedCandidate` | custom | Score reached, or segment assigned | Mid-funnel optimisation once volume allows | | `ViewContent` and `Lead` are Meta **standard** events, selectable as campaign objectives with no extra setup. The other three are custom and need a **Custom Conversion** in Events Manager before you can optimise toward them. | | | | || โš ๏ธ Lead means "clicked through to the destination", not "applied". The actual application happens in the client's ATS, out of reach of a pixel. Be precise about this when reporting, or you will promise a client something the number does not support. # Two ways to profile people Both are optional. Configure neither and you get four clean events. **Scoring** โ€” for "how interested is this person?". The story adds points as people answer; when the total crosses a threshold, `QualifiedCandidate` fires and the score travels as `value`, which is what makes value-based lookalikes possible later. **Segmentation** โ€” for "which role fits this person?". The story writes a category into a variable; that category rides along as a `segment` parameter on every event after it is known. | ๐Ÿ’ก Send categories as a parameter, never as event names. Resist FitEngineering, FitWarehouse, and so on. One event carrying segment: "engineering" gives you unlimited segments inside the fixed schema โ€” build one Custom Conversion per segment in Events Manager and each becomes its own audience. โš ๏ธ **Keep segment values to neutral role labels.** `engineering`, `warehouse`, `customer-support`. Never age, nationality, parental status, salary expectation, language or accessibility needs. A segment is inferred personal data about an individual, sent to an advertising platform, in a recruitment context โ€” encoding anything that proxies a protected characteristic is a problem both under Meta's terms and under employment law. # Installing it **Project settings** โ†’ **Tracking & scripts** โ†’ **Footer scripts**. Admin only. Paste the code below, wrapped in a pair of script tags, and change the config block at the top. Do **not** also paste the base pixel code Meta offers you in Events Manager โ€” the bootstrap is already included here, and pasting both initialises the pixel twice. You can skip Meta's noscript image fallback too. It exists for visitors with JavaScript disabled, and a story is a JavaScript app โ€” those visitors see nothing to track. | ๐Ÿ’ก Only the four lines inside CONFIG change per client. Everything below it is identical for every story we ever ship. ``` ``` # What the snippet already handles * **Resumed sessions.** Reloading a finished story sends only `PageView`. See *Why completions get over-counted* for why this matters. * **Once per page.** Each event fires at most once per load. * **The story's own tracking toggle.** If tracking is disabled in story settings, the script stops sending. * **Late consent.** With `requireConsent: true` nothing is sent until your consent tool calls `window.intractiveMetaConsent()`. At that point everything the visitor already earned is replayed rather than lost. # Verifying it Open the story in a **private window** โ€” not a story you have already finished โ€” and run this in the browser console: ``` performance.getEntriesByType('resource') .filter(e => e.name.includes('/tr')) .map(e => new URL(e.name).searchParams.get('ev')) ``` On a fresh start you should see `["PageView", "ViewContent"]`, each exactly once. Anything appearing twice means the pixel is loaded twice โ€” check whether Tag Manager is also running Meta tags on this project. To confirm the right pixel is live: ``` Object.keys(window.fbq.instance.pixelsByID) ``` | ๐Ÿ’ก This console check is the source of truth, not Events Manager. It tells you what the browser actually sent, with no reporting delay in between. Use it first, every time. # Reading Events Manager without being misled Events Manager is slow, and its default view hides today. Three traps, all of which have cost us time: | Trap | What to do | | ---- | ---- | | **The date range ends yesterday** | The default range excludes today. A brand-new pixel has only today's data, so it always looks dead. Set the range to **Today** before concluding anything | | **New events take hours to register** | Meta says 30 minutes. For an event name or a dataset it has never seen, it has taken several hours, then everything appeared at once. Verify on the wire and wait | | **The overview can contradict itself** | We have seen the table report no activity while its own chart plotted dozens of events. When they disagree, trust neither โ€” go back to the console check | || โš ๏ธ "Finish setting up Meta Pixel ยท 0% complete" is onboarding UI, not a diagnosis. It stays at 0% until Meta processes your first events. It is not telling you the pixel is broken. โœ… **Quick checklist** * One route only โ€” Tag Manager or footer script, never both. * Change the pixel ID; leave everything below CONFIG alone. * Don't paste Meta's base code as well. * Use the fixed five-event schema; send categories as a `segment` parameter. * Neutral role labels only. * Test from a private window and check the console, not Events Manager. * Set the Events Manager date range to Today before judging anything.