Conversion Tracking in 2026: A Cross-Platform Implementation Library
The hub for conversion tracking across Google, Meta, LinkedIn, TikTok, Reddit, Microsoft, and Pinterest — the decisions to make before you touch a tag, plus a per-platform guide index.

Updated July 22, 2026.
Conversion tracking is not one task. It is a chain of decisions: what business outcome matters, which data source can observe it, what identifier preserves the connection to the ad click or view, which event the platform can optimize toward, and how the team proves that the event is complete, unique, timely, and correctly valued.
Verification boundary. This guide was checked against official the seven advertising platforms covered here advertiser help, developer documentation, and release notes available on July 22, 2026. It does not rely on agency blogs, community posts, or third-party tutorials. Interface labels can differ during account-level rollouts. Where the official documentation describes a pilot, gradual rollout, regional limit, or incomplete availability, the guide says so rather than assuming access.
This library covers Google Ads, Meta, LinkedIn, TikTok, Reddit, Microsoft Advertising, and Pinterest. Each guide follows the platform's current terminology. It does not pretend that a Meta custom conversion, a TikTok custom event, a Google Ads conversion action, and a Microsoft Advertising conversion goal are interchangeable. They solve related problems, but their eligibility, setup, attribution, and bidding behavior differ.
Choose the guide you need
| Platform | Best starting point | Important 2026 issue |
|---|---|---|
| Google Ads | Website tag, GA4 import, phone, app, or offline/CRM conversion | June 2026 changes unified enhanced-conversion controls and shifted many offline uploads toward Data Manager. |
| Meta | Dataset/Pixel plus standard events; add Conversions API where appropriate | Website, app, offline, and messaging events now converge around datasets and Conversions API. |
| Insight Tag and Website Actions for web; CAPI or CSV for CRM outcomes | Qualified Lead is the current lifecycle category to favor; conversion rules must be associated with ad sets. | |
| TikTok | Pixel Event Builder or custom code; pair with Events API for resilient web measurement | Custom events report and build audiences but are not eligible for campaign optimization. |
| Pixel, Event Setup Tool, partner integration, or Conversions API | Eight standard events; Pixel and CAPI implementations require event deduplication. | |
| Microsoft Advertising | UET website goals, app goals, or offline conversions | UET Conversions API is a pilot and is not available to every advertiser. |
| Pinterest tag events, enhanced match, and Conversions API | Twenty current event types; dynamic retargeting requires specific product event metadata. |
The cross-platform decisions to make before touching a tag
1. Define the business event, not just the webpage
A thank-you page can be a useful trigger. It is not the business definition of a conversion. Write the event in plain language first: “a new visitor submitted a demo request,” “a sales-qualified lead was accepted,” “an order was paid and not merely initiated,” or “a subscription started after trial.” Then choose the platform event that most closely represents that action.
When the platform offers a standard event that fits, use it. Standard events are usually the safest option for optimization, reporting consistency, and downstream features. Use a custom event only when the business action is materially different and the platform supports the intended use. On TikTok, for example, custom events are not eligible for campaign optimization; using one for a core outcome would create a reporting event that bidding cannot use.
2. Decide where the source of truth lives
| Outcome | Usually observed first | Better source of truth |
|---|---|---|
| Page view or content engagement | Browser | Browser or analytics event |
| Form submission | Browser or form system | Form backend or CRM when available |
| Purchase | Browser checkout | Order system / server |
| Qualified lead | CRM | CRM |
| App install or in-app action | App SDK or MMP | App analytics/MMP |
| Phone call | Call extension or forwarding number | Call reporting / CRM |
| In-store purchase | POS or CRM | Server/offline upload |
The closer an event is to revenue, the less comfortable you should be relying on a page-load trigger alone. A server, CRM, order system, or mobile measurement system usually has a better view of whether the action actually completed.
3. Choose browser, server, or both
Browser tags are useful because they observe page context and ad-click identifiers quickly. Server integrations are useful because they can send authoritative outcomes, customer matching fields, and later lifecycle events without depending entirely on browser execution. “Server-side” does not mean “send everything twice.” When both paths send the same event, implement the platform's deduplication method and use a shared event identifier.
4. Preserve the identifiers you will need later
Offline and CRM attribution fails most often before the lead ever reaches the CRM. Capture the relevant click identifier, landing URL, consent state, and first-party identifiers when the conversion begins; store them with the lead or order; and send the lifecycle event within the platform's supported time window. A later CSV upload cannot reconstruct an identifier that was never saved.
5. Separate reporting events from optimization events
Do not place every measurable action into the bidding set. A pricing-page view, a form start, a form submission, a qualified lead, and a closed customer can all be useful signals, but they are not equally valuable. Use the platform's primary/secondary, inclusion, goal-selection, or ad-set association controls to keep automated bidding focused on outcomes with enough volume and meaningful business value.
Minimum event specification
Before implementation, write one row for every event:
| Field | What to record |
|---|---|
| Business definition | The exact condition that makes the event true |
| Platform event/category | The official event or conversion type selected |
| Trigger source | Browser, server, app, CRM, call system, or offline file |
| Counting rule | Once per lead/order or every occurrence |
| Value rule | Fixed value, dynamic revenue, margin, lead value, or no value |
| Currency | ISO currency code where required |
| Unique identifier | Transaction ID, order ID, event ID, or platform-specific key |
| Match data | Permitted click ID and/or consented first-party identifiers |
| Optimization status | Eligible and selected, eligible but secondary, or reporting only |
| Owner | Person responsible for source data, implementation, and QA |
| Test evidence | Timestamp, test record, platform status, and screenshots/logs retained internally |
Universal QA sequence
- Inspect the base integration. Confirm the correct account/data-source ID fires once on every intended page and not on excluded environments.
- Trigger each event deliberately. Use a unique test order, lead, or event identifier so it can be traced end to end.
- Validate the payload. Check event name, timestamp, URL, value, currency, product or content identifiers, click identifiers, and permitted matching fields.
- Test duplicate protection. Reload, navigate backward, resubmit, and send the matching server event. Confirm one business action becomes one counted event.
- Confirm platform receipt. Use the platform’s official helper, test-events view, diagnostics, or event manager.
- Confirm optimization eligibility. Receipt alone does not prove the event is attached to the right campaign/ad set or included in bidding.
- Reconcile against the source system. Compare platform events with orders, CRM records, calls, or app events for the same period.
- Document the release. Record event definitions, versions, owners, consent assumptions, and test evidence before campaigns depend on it.
What this library does not assume
- That every advertiser has every beta or pilot.
- That the same menu labels appear in every account during gradual rollouts.
- That a browser event is accurate simply because a helper extension sees it.
- That server-side tracking bypasses consent, platform policy, or regional law.
- That more conversion events automatically improve bidding.
- That an event received by the platform is necessarily attributed to an ad.
Verification record
Technically verified: July 22, 2026
Official-source rule: Every platform-specific instruction and feature statement in this article is grounded in an official platform source. The implementation recommendations are editorial guidance from The Ad Spend and are labeled as such.
Known limits at publication
- Account interfaces can vary during staged rollouts.
- Platform eligibility, country availability, objective support, and minimum-volume requirements can change.
- The guides do not replace legal review of consent, privacy, health-data, financial-data, or sensitive-data obligations.
Official sources consulted
- Google Ads: Set up your conversions
- Meta: About Conversions API
- LinkedIn: Create conversions in Campaign Manager
- TikTok: Events API
- Reddit: Conversion Events
- Microsoft Advertising: Conversion goal types
- Pinterest: Track conversions with the Pinterest tag
Related conversion tracking references
The Ad Spend
Conversion setup decisions age badly once the people who made them move on. The Ad Spend keeps the operating record around changes, timing, and decisions, giving analysts cleaner context when they interpret what a test or model is actually measuring. See History.