Growth
Advertising measurement that tells the truth about a cash-on-delivery market
Ad platforms learn from the events you send them. Send the wrong event at the wrong moment and they will diligently find you more of exactly the wrong customer. Akkad's growth tooling is built around that single problem — reporting what actually happened, when it actually happened, without asking you to change how you work.
Most commerce platforms treat advertising integrations as a settings page — paste an ID here, tick a box there. That is roughly half of the job. The other half is deciding what counts as a conversion, and in a market where the majority of orders are paid to a courier days after they are placed, that decision is worth more than the integration itself.
The three pieces on this page fit together. Pixels give the platforms something to attribute against. Deferred purchase events control when a sale is reported as a sale. Catalog sync keeps what you are advertising in step with what you actually have. Shopper sign-in sits alongside them because it is what turns a stream of anonymous checkouts into customers with a history.
01
Pixels belong to a surface, not to an account
A Meta pixel and a TikTok pixel are configured per storefront and per landing page, not once for the whole business. If you run three landing pages for three products and a main store, each can report into its own pixel, its own ad account and its own campaign structure. If you would rather they all share one, that works too — it is the same field, filled in with the same value.
On the browser side the storefront captures the identifiers the platforms use to reconcile a click with a conversion, so that an event sent later can still be matched to the ad that produced it. Nothing about this requires you to install a tag manager or paste code into a template.
02
What you can paste into a pixel field
Nobody has the pixel ID to hand. What people have is whatever their screen was showing when they were asked for it, so the field accepts all of it and mines the ID out.
| What you paste | What happens |
|---|---|
| The entire base-code snippet | The full block of JavaScript Meta or TikTok hands you. The ID is extracted from the initialise call. |
| The noscript fallback URL | The tracking image URL from the bottom of the snippet. The ID is read from its query string. |
| An Events Manager URL | The address bar of the page you were looking at when you went hunting for the number. |
| The bare ID | Digits for Meta, alphanumerics for TikTok, each within the length the platform actually issues. |
There is deliberately no fallback that simply grabs the longest run of digits it can find. That fallback looks helpful and is a trap: pasted Meta base code contains a version number, and a greedy match would happily save it as your pixel ID, after which every event goes nowhere and nothing appears broken. Input that cannot be recognised returns a clear, translated error instead of being silently discarded — and the same extraction logic runs in the storefront, on landing pages and inside all four apps, so wherever you paste it you get the same answer.
03
The showpiece
Purchase should mean paid, not placed
When an order is paid on delivery, firing a Purchase event at checkout tells the ad platform that the sale is done. It is not done. Some of those orders will be refused at the door, some were never real, and the algorithm cannot tell the difference — so it optimises for people who place orders, which is a genuinely different population from people who pay for them. Spend enough on that signal and you will have bought yourself an audience of non-buyers. Akkad lets you move the Purchase event to the moment the order actually became real to you.
You choose the moment
Report at checkout, when the order reaches processing, or when it is marked delivered. Delivered is the honest signal in a cash-on-delivery market; processing is the middle ground for merchants who confirm by phone before dispatch.
Sent server to server
A deferred event goes through the Meta Conversions API and the TikTok Events API, because by the time it fires the shopper's browser is long gone. Nothing needs to be open for the event to be delivered.
The browser and the server never both fire
When an order is deferred, the checkout response says so and names which platforms are deferred, so the page suppresses its own event. A surface is only ever deferred for a platform where both a server token and a usable pixel ID exist — otherwise the browser event stands. There is no configuration in which a purchase is counted twice.
04
Three moments you can count a purchase
| Trigger | Fires when | Best for |
|---|---|---|
| On order | The shopper completes checkout. The browser fires it, as it always has. | Prepaid stores, and anyone who wants the fastest possible feedback loop while volumes are still small. |
| On processing | The order first reaches processing or beyond — typically when you have confirmed it. | Merchants who call to confirm before dispatch. Filters out the obvious junk without waiting for delivery. |
| On delivered | The order is marked delivered, whether by your team or by a courier status sync. | Cash on delivery. The event now means money changed hands, which is what you were trying to optimise for all along. |
TikTok does not support Iraqi dinar, so amounts are converted to US dollars at a fixed rate before being sent — the same constant is used by the storefront and the landing page, so the browser and the server never report a different figure for the same order.
05
How deferred events are sent
A deferred event is a promise to report something later, which means the sending machinery has to be honest about failure, about time, and about orders that stop being sales.
Tokens are read live, and never leave the server
Conversions API access tokens are fetched at the moment of sending rather than copied onto the pending event, so rotating a token takes effect immediately. The public storefront configuration exposes only which trigger is in use — never a token.
Attempts are bounded in both directions
A pending event is retried up to ten times with widening gaps, and abandoned entirely after fourteen days. Meta's click attribution window is seven days; an event delivered three weeks late is not a measurement, it is noise.
Cancelled and returned orders are dropped
An order that has not yet reported and then gets cancelled or returned is discarded rather than sent. The whole point of deferring was to avoid reporting sales that did not happen.
Blocked orders never report at all
Orders from customers on your block list are silently refused and produce no pixel events in either direction. Fake purchases are the most expensive thing that can enter an ad account, because the platform will believe them and go looking for more.
Nothing else in the system had to change
Deferred events are found by a background job that scans for orders now due to report, running every minute over batches of two hundred. There are deliberately no hooks inside the order routes, the bulk status updater, or the carrier status sync — which is why a courier reconciliation that flips forty orders to delivered fires forty events correctly without the shipping code knowing that pixels exist. Event delivery is a property of the data, not a side effect scattered across every place that writes a status.
06
Your catalogue on Meta, kept current by difference
One catalog per business, bound to a specific storefront so every product link points at a page that exists. Connected through Facebook Login for Business — create a new catalog or adopt one you already have.
Driven by a hash diff, not by hooks
Each run recomputes what every published item should look like on Meta and pushes only the rows that changed, in batches of five hundred. Nothing that writes an item — the app, an Excel import, an offline sync flushing after a day without signal, an image upload — needs to know the catalog exists.
Deletions fall out of the comparison
An item you deleted or unpublished simply stops appearing in the computed set, which makes it a delete. There is no separate teardown path to forget to call, and no orphaned products advertising something you no longer sell.
Price semantics are inverted, and handled
Meta's price field means the pre-discount price and its sale price means the current one, which is the opposite of how Akkad stores them. The mapping is done explicitly, because getting it backwards advertises your compare-at price as the price you are charging.
Barcodes only sent as GTIN when they are one
A barcode is submitted as a GTIN only when it is a genuine eight, twelve, thirteen or fourteen digit code. Anything else — an internal code, a shortened number — is sent as a manufacturer part number instead, because Meta silently drops non-standard GTINs and you would never find out.
Category visibility is part of the diff
Hiding a category on one storefront changes what that storefront advertises. Per-website visibility toggles are included in change detection, so the catalog matches the store rather than the raw item list.
Scheduling that stays cheap
Businesses are synced in a bounded rotation, oldest-checked first, with a hard cap of fifty per tick. The cost of the sync stays flat as more businesses connect, which is why it can run every few minutes for everyone rather than nightly for a lucky few.
07
Shopper sign-in on every domain you own
Google and Apple sign-in normally requires registering each origin with the provider. That does not survive a platform where every merchant has their own subdomain and some have their own domain, so Akkad routes all of it through one broker.
- 1
The storefront opens the broker
A popup goes to a single Akkad-operated sign-in origin. That one address is the only thing ever registered with Google and Apple, which is why unlimited subdomains and arbitrary custom domains all get social sign-in without any of them registering anything.
- 2
The provider handles the login
The broker forwards to Google or Apple with signed state. The shopper sees the normal, familiar consent screen at the normal, familiar address.
- 3
The code is exchanged on the server
The callback exchanges the authorisation code server-side as a confidential client. The OAuth secret never reaches a browser, on any domain, at any point.
- 4
The token is returned to the exact calling origin
The resulting identity token is posted back only to the origin that opened the popup, and only if that origin matches an active subdomain or an active custom domain. The broker's job ends there — the storefront's own sign-in endpoint independently verifies the token before trusting anything in it.
08
What each of these needs
| Capability | Plan | Notes |
|---|---|---|
| Meta and TikTok pixels | Any plan with a storefront or landing page | Configured per surface. Browser-side events work everywhere. |
| Deferred purchase events | Any plan with a storefront or landing page | Requires a server access token for the platform in question; otherwise the browser event stands. |
| Meta catalog sync | Pro and above, trials excluded | Available on the Inventory app, enabled in stages while Meta completes its review. |
| Customer accounts | Team and above | Three modes per storefront — off, optional, or required before checkout. Falls back to off if the plan stops covering the site. |
| Storefront online payments | Pro and above, trials excluded | Covered in full on the payments page. |
09
Questions
If I switch to reporting on delivery, do I lose attribution?
Not for orders that are delivered within the platform's window. Events are sent server to server with the identifiers captured at checkout, so a click can still be matched days later. Events are abandoned after fourteen days precisely because attribution beyond that point is not real anyway.
Will I get double-counted purchases if I have both a pixel and a server token?
No. An order is either deferred or it is not, and the checkout response tells the page which platforms have been deferred so it can stay quiet for those. Deferral only happens when both a token and a working pixel ID exist for that platform, so there is no state where both fire.
Do I have to change anything in my daily workflow?
No. Events are found by a background scan over your orders rather than by hooks in the places that update them. Marking an order delivered by hand, updating fifty at once, or having a courier sync flip them all produce the same result.
What stops my catalog from advertising items I have sold out of?
Availability is computed from whether the item manages stock and how much it has, and it is part of the payload that gets compared each run. A sold-out item changes its hash and is pushed on the next sync.
Can shoppers sign in on my own domain, not just an Akkad subdomain?
Yes, and that is the point of the broker. Custom domains are allow-listed as valid origins the moment they are active, so social sign-in works on your domain without you registering anything with Google or Apple.
Do I ever see a shopper's email address?
You see it in the merchant-side customer account view, which is read-only and shows email, display name, linked providers, order count, total spent and last login. Public surfaces never expose it — a published review shows the shopper's own profile name and no email.
Related
Online store
The storefront these pixels and catalogs describe — templates, style presets, custom domains and SEO.
Landing pages
One product, one page, its own pixel and its own payment mode — the surface most ad spend lands on.
Customers
Tags, debts, and the block list that keeps fake orders out of both your books and your ad data.