How delivery works

A destination receives your attributed installs. You set each one up by pasting the platform’s own credentials: there is no “connect” sign-in. Every destination starts in test mode, shows you the exact payload it would send, and goes live only when you say so.

#Plans

Destinations are part of the Standard and Enterprise plans. On Free they cannot be created, tested or switched live (402, plan_required), and nothing reported while on Free is ever sent later. A website can have up to 10 destinations on Standard and 20 on Enterprise. After a downgrade, destinations over the new limit are paused, whatever their own mode, until the owner picks which to keep; nothing is deleted. See Plans and limits.

#Modes

Going live applies to installs recorded from then on. Test-mode payloads and installs from before the destination existed are never sent later.

#Send a test

Send test checks the credentials you saved without sending a real install:

• GA4 sends a sample event to GA4's validation server. GA4 checks the event format but does not confirm API secrets.
• Google Ads sends a validate-only request, which checks access to the account and conversion action. Nothing is recorded.
• Meta and TikTok need the test event code from the platform's Events Manager and send an event named CLItrailConnectionTest.
• X Ads sends a signed request with an empty list of conversions: X checks the credentials, and nothing can be recorded. X has no test events, so read the prepared requests under Install events in test mode.
• Webhooks send a signed test.ping and show the status code your endpoint returned.

#Go live

Go live is refused until the destination can deliver:

#Which installs are sent

• Events. Each destination sends the event types you tick. Ad platforms default to completed installs; GA4 and webhooks also send first runs. install_started is an attempt, not a conversion: only webhooks receive it, and the other destinations refuse it (unsupported_event).
• Resolution. GA4 and the ad platforms receive matched installs. They receive reconstructed (probable) installs only when you turn on Include reconstructed installs on that destination. Webhooks receive every install with its resolution.
• Global Privacy Control. Google Ads, Meta, TikTok and X Ads never receive a touch recorded under GPC.
• Identifiers. Each platform needs its own ID on some touch of the journey: a GA4 client ID for that measurement ID, a Google click ID or session attributes, fbc or fbp, ttclid or ttp, a twclid. Without one, nothing is queued for that platform. Each platform follows your attribution policy: its most recent identifier under latest visit, its earliest under first visit. A click is dated by its own evidence (the visit whose URL carried it, the _gcl_aw or _fbc cookie time, Google's session start or the TikTok click date), so a cookie re-read on a later visit never outranks a newer click on another domain.

#Retries and time limits

Retries wait 1 minute, 5 minutes, 15 minutes, 1 hour, 3 hours, 6 hours, 12 hours, then 24 hours, or longer when the platform sends Retry-After (up to a day). Every retry reuses the same event ID, so Google Ads, Meta, TikTok and your webhook endpoint can ignore a copy they already have. Meta and TikTok retries stop before their 48-hour deduplication window closes, checked when each batch is sent; a resend that could arrive at 48 hours or later is marked uncertain instead of risking a double count. X Ads retries stop at the same 48 hours, but X documents deduplication only against its pixel, not between two API sends, so X Ads resends only requests X answered with an error or never answered.

• When a platform refuses the whole request, CLItrail resends the events one at a time so one bad event cannot block the others (Google Ads, Meta, TikTok, X Ads).
• When a platform refuses a credential, the events stay queued within the platform's own time limit and are tried about once an hour; refusals do not use up attempts or start the deduplication window. Replacing the credential or correcting the account or pixel resumes delivery at once. The destination's health shows the error.
• A send interrupted by a restart or crash is retried for Google Ads, Meta, TikTok and webhooks, which deduplicate it, and for X Ads within its 48 hours, where such a resend can count twice; it becomes uncertain for GA4. A Node server that is shutting down starts no new batch and waits for the requests in flight.
• Destinations are delivered side by side, each one run at a time, so a slow endpoint or a large backlog holds up only its own queue. An endpoint that does not answer holds its queue for a minute, or its Retry-After.
• A webhook that answers 410 Gone pauses its destination; 401, 403, 404, 408, 429 and 5xx are retried. The change is recorded in the audit log.
• Redirects are never followed; a 3xx answer counts as a failed delivery.

X Ads follows its own rules, on the X Ads page.

#Delivery statuses

Each destination card shows its health (ok, error, auth_error, or never before the first delivery), the last error with any secret removed, and counts per status for the last 30 days.

#Managing destinations

• One destination per target: one per GA4 measurement ID, Meta pixel, TikTok pixel, X pixel event, Google Ads conversion action or webhook URL (duplicate_destination).
• Members create and edit destinations; admins and owners remove them. See roles.
• Credentials are write-only and kept in a separate secret store. See Security and secrets.
• Every request sent to a platform is recorded in Logs with its exact body, credentials redacted.
• Removing a destination deletes its credentials and cancels everything it had not sent.
• Every change is recorded in the website's audit log in Settings, without secret values.