Ad network integrations
Native integrations vs. postbacks vs. conversion APIs
An integration logo can represent account sync, conversion feedback, a generic callback, or only planned support. Ask what data moves in each direction.
A native integration connects to a provider’s account and implements specific provider workflows. A postback sends a configured server request. A conversion API accepts provider-specific event data. These connections can work together, but they are not interchangeable.
The fastest way to evaluate an integrations page is to ignore the logos and ask what data moves in each direction.
Four questions for every connection
For each provider, ask:
- Can the user connect an account?
- Can the tracker discover campaigns or conversion actions?
- Can it import spend and performance reports?
- Can it send conversion feedback back to the provider?
A provider can support one answer without supporting the other three.
What a native integration means
A native integration uses the provider’s own authentication and API contracts.
Depending on the provider, it may support:
- OAuth or provider credentials;
- account selection;
- campaign discovery;
- scheduled spend sync;
- recent or real-time reporting;
- conversion-action discovery;
- queued conversion uploads;
- provider-specific diagnostics.
Native does not mean complete. A product might connect an account and import reports without sending conversions. Another might send conversions but not discover campaigns.
State the exact capability instead of using “native” as a blanket quality label.
What a postback does
A postback is a server-to-server request triggered by an event.
There are two common directions.
Inbound postback
An advertiser or affiliate network reports a conversion to the tracker. The URL usually includes a Tracked click reference plus optional event, payout, currency, and transaction fields.
The tracker uses that reference to associate the conversion with the original campaign click.
Outbound postback
After recording the conversion, the tracker sends a provider-configured request back to the traffic source. That request can carry the source click ID, mapped event name, value, and other supported fields.
Postbacks are flexible. They can work with providers that do not have a full account connector. They also require careful configuration and do not automatically provide spend sync, campaign discovery, or rich provider diagnostics.
What a conversion API adds
A conversion API is a provider-defined event interface. It usually has stricter fields and behavior than a generic postback.
It may require:
- an authenticated provider account;
- a pixel, dataset, or conversion-action destination;
- a provider click identifier;
- event timestamps and action source;
- value and currency;
- consent fields;
- customer information under specific rules;
- test-event codes;
- deduplication identifiers;
- batch and rate-limit handling.
The benefit is a provider-aware response and workflow. The cost is that every provider needs its own implementation and ongoing maintenance.
Why “supports conversions” can be ambiguous
The phrase might mean:
- the tracker can receive a conversion;
- the tracker can attribute it to a click;
- the tracker can fire a generic outbound URL;
- the tracker can call a native provider API;
- the provider accepted the event;
- the event appeared in reporting;
- the event became eligible for bidding.
Those are separate checkpoints. A trustworthy product description names the checkpoint it has actually verified.
Where Tracked is today
Status: Provider connection depth varies. Google Ads click-based uploads are shipped; Meta’s automatic postback-to-CAPI workflow is partial, and Universal CAPI remains a product direction.
Google Ads
Google account connection, campaign discovery, scheduled reporting, conversion-action configuration, and queued offline click-conversion uploads are available. Uploads use Google click identifiers through the Data Manager API; this is not enhanced conversions for leads.
Taboola
Credential-based connection, campaign discovery, scheduled reporting, a recent-reporting path, and configured conversion postbacks are available.
NewsBreak
API-key connection, campaign discovery, scheduled reporting, history repair, and configured conversion postbacks are available.
Meta
Tracked can connect a Meta account, resolve or create its dataset, and send a synthetic PageView to check the connection. An authenticated backend route can forward caller-supplied CAPI events. There is no completed workflow that maps each inbound Tracked postback to a Meta event and sends it automatically, so do not assume Tracked hashes customer data or handles Pixel/CAPI event-ID sharing and deduplication.
Other providers
Tracked can attribute inbound conversions from custom traffic sources when the campaign preserves the required click reference. Provider conversion delivery remains provider-specific; a callback does not imply account discovery, spend import, or a complete conversion API workflow.
Native connector depth remains provider-specific; a configurable postback can cover a traffic source without pretending it has the same account discovery, spend import, or diagnostics as a native connection.
How to compare integration coverage
Build a matrix with capabilities as columns, not one yes-or-no “integration” field.
| Capability | What to verify |
|---|---|
| Connect | Authentication works for a real account |
| Discover | Accounts, campaigns, or actions can be selected |
| Import | Spend and performance data arrive on a documented cadence |
| Attribute | Provider click IDs are captured and stored |
| Receive | Inbound conversions attach to the correct click |
| Send | Outbound feedback reaches the intended provider destination |
| Diagnose | Attempts, skips, errors, and provider responses are visible |
| Backfill | Eligible earlier events can be re-sent safely |
Score each provider separately. Do not multiply one working connector across every logo on the page.
Which connection should you use?
Use a native integration when you need account data, campaign discovery, provider actions, and richer diagnostics.
Use an inbound postback when an advertiser or network needs to report the verified conversion to Tracked.
Use an outbound postback when the traffic source accepts a configured server callback and a full account connection is unnecessary.
Use a conversion API when the provider offers a structured event interface and the campaign needs its provider-specific measurement or bidding workflow.
Many production setups use more than one.
How this connects to the page workflow
Tracked keeps provider configuration beside the campaign route, hosted page, click IDs, conversion events, and report. That helps the buyer diagnose the complete path instead of debugging each integration in isolation.
The practical rule
Do not count logos. Verify authentication, reporting, attribution, conversion delivery, and diagnostics for each provider. A generic postback can be useful without being a native integration, and a native connection can still have partial coverage.
Frequently asked questions
Does a postback count as a native integration?
No. A postback is a configured server request that can receive or send a conversion. A native integration implements named provider workflows such as authentication, account discovery, spend import, action mapping, or provider-specific diagnostics.
Does Tracked support every ad network natively?
No platform can treat every network as the same native API. At launch, Tracked supports a mix of native connectors, configurable postbacks, and Universal CAPI, with a separate identity, mapping, delivery, and diagnostics contract for each supported provider.
What should I verify before trusting an integration logo?
Verify what data moves, in which direction, on what schedule, and with which diagnostics. Authentication, spend import, click attribution, inbound conversion receipt, and outbound feedback are separate capabilities.