Conversion tracking
Affiliate Tracker Migration Checklist: IDs, Domains, and Postbacks
A cross-vendor migration checklist for preserving old and new click cohorts, callback ownership, page links, delayed conversions, and rollback paths.
To migrate affiliate trackers, move new traffic in controlled stages while preserving the old system's ability to resolve outstanding click IDs and callbacks. Document domains, page links, network parameters, event ownership, and rollback before changing live URLs. Importing campaign settings is not the same as migrating click history, and a callback reaching a server does not prove a conversion was matched or attributed.
This is a Tracked-authored operational checklist, not a report of a migration we performed or a guarantee of zero loss. The migration opportunity and vendor migration reference were identified in October 29 research. Tracked source guidance was reviewed October 30. No production campaign, callback, DNS, or account setting was changed.
What are you actually moving?
Separate five jobs that are often bundled into the word migration:
| Migration job | What it moves | What it does not establish |
|---|---|---|
| Configuration | Campaign names, offers, route definitions, and supported mappings | Historical click ownership or identical rule behavior |
| Page assets | Authorized HTML, images, styles, and scripts | Runtime compatibility or working offer links |
| New click collection | A new campaign entry point and newly issued tracker IDs | Resolution of IDs issued by the old tracker |
| Conversion handling | Authorized callbacks, event mappings, and revenue/status handling | Automatic ad-platform delivery or historical backfill |
| Reporting | Exports or supported report imports | Identical attribution models, time zones, or cost allocation |
A vendor's migration service can help with some of these jobs. Obtain its exact scope. For example, ClickFlare's migration page is a first-party reference identified in the October 29 research; it is not evidence that another vendor offers the same service or that every historical record transfers.
If you need one specific move, use the existing ClickFlare switching guide, RedTrack switching guide, or ThriveTracker switching guide. This checklist addresses the cross-vendor handoff, not a new claim that Tracked imports those products.
1. Inventory the live path before rebuilding it
Document the current path from ad click to offer and conversion. Include owned and third-party systems, not just objects visible inside the tracker.
Record:
- Campaign entry URLs and where ads or other systems store them.
- Tracking and landing-page domains, DNS ownership, certificates, and renewal access.
- Hosted, proxy, redirect, or external page destinations.
- Every offer URL, tracker macro, network sub-ID field, and traffic-source click-ID field in use.
- Callback endpoints, event names, status mappings, payout units, and currencies.
- Systems that send conversion feedback to ad platforms.
- Report time zones, attribution rules, reporting delays, and cost sources.
- Access needed for the transition, restricted to authorized operators.
Use the click-ID reference to distinguish the ad platform's identifier from the tracker ID used to match an affiliate conversion. They are not interchangeable just because both travel in a URL.
2. Keep old and new click IDs in separate cohorts
A tracker-issued ID points to a click in the system that created it. Changing a callback hostname does not recreate that click in a new database.
Use an ownership worksheet:
| Click cohort | Tracker that issued the ID | Callback route to preserve |
|---|---|---|
| Clicks before the cutover | Old tracker | An authorized path that can still resolve old IDs |
| Clicks after the approved cutover | New tracker | The validated path for newly issued IDs |
| Delayed conversion from an older click | Old tracker unless a documented migration proves otherwise | The old cohort's agreed callback route |
Do not apply this table as a claim about a vendor's undocumented internal IDs. Confirm the actual network and tracker behavior before configuring the transition.
If the network supports only one callback destination, resolve that limitation before changing it. Ask whether the network supports an explicit cohort-aware arrangement, a documented migration mechanism, or another authorized transition path. If it does not, adjust the cutover design or defer the move. Do not assume you can distinguish cohorts by inspecting an arbitrary ID string.
Keep an access-controlled migration log of the cutover and mappings. Do not expose callback secrets, authentication tokens, or personal data in a shared spreadsheet.
3. Rebuild URLs and macros deliberately
The new tracker may use a different macro name, offer-click path, or page integration. Copying the old URL character-for-character is not necessarily correct.
Review entry URLs, page-to-offer links, hidden form values, encoding, and query values required downstream. Confirm what each system preserves automatically and what requires explicit forwarding. In Tracked, required offer-query values are configured through the applicable macros; do not assume every incoming parameter is automatically appended at click-out.
Do not replace one tracker token with a guessed token from another product. Use the current vendor documentation and the required postback setup for the actual integration.
Page import also needs a file-level review. An uploaded archive does not establish that forms, scripts, runtime dependencies, or offer links work in the replacement environment. The landing-page QA guide provides a separate pre-spend checklist.
4. Name one owner for each outbound conversion event
During an overlapping subscription period, two trackers may know about a transaction. That does not mean both should send it to the same ad-platform destination.
For each event and destination, document the authorized sender, required identifiers, consent handling, mapping, and deduplication behavior. A transaction ID can help identify a business event; it does not replace the tracker click ID used to find the originating click.
If callbacks can be repeated or mirrored under an authorized design, verify how each recipient handles repeat events, status changes, and revenue updates. Two successful HTTP responses do not establish that duplication was prevented.
Do not resend conversions simply to make dashboard totals agree. First separate receipt, matching, approval, delivery, acceptance, and attribution. The event-mapping and backfill guide explains why those boundaries matter.
5. Define acceptance evidence before switching paid traffic
A successful page load is one piece of evidence, not a completed migration.
| Stage | Evidence to obtain within your authorized migration scope |
|---|---|
| Entry | Expected campaign, source context, and newly issued tracker ID |
| Page | Correct destination, working assets, and intended form or offer action |
| Offer handoff | The correct tracker click ID reaches the supported network field |
| Callback | An authorized callback matches the intended click and event |
| Reporting | Status, revenue, currency, time zone, and reporting window are understood |
| Provider feedback | Where required, delivery ownership and destination diagnostics are established separately |
| Old cohort | Outstanding old-click callbacks still follow the agreed resolvable path |
| Rollback | A named operator can restore new-traffic routing without abandoning either cohort |
This checklist describes a proposed transition, not a migration we executed. Use only traffic and event data you are authorized to create or inspect; respect each network's test-event rules.
6. Stage the cutover and keep a rollback record
Choose a transition design that fits the traffic source's URL rules and your network's callback constraints. If a controlled subset can move, document the campaign or route identifiers that define that subset. If it cannot, obtain another explicit cutover design before launch.
Write down:
- The exact new entry URLs and the assets that will change.
- The person responsible for those changes.
- The evidence required to continue, pause, or roll back.
- The old and new callback ownership during overlap.
- The route used for new traffic after a rollback.
- The retention plan for clicks already issued by either tracker.
A rollback redirects future activity; it does not erase clicks already issued by the new tracker. Those clicks can still produce delayed conversions and need their own callback path after the rollback.
Do not prescribe a universal one-day or seven-day transition. Use actual network conversion windows, approval/reversal behavior, callback timing, contractual retention, and operating constraints to determine the overlap.
7. Reconcile comparable reports before retiring the old service
Compare the same click cohorts, date boundaries, event definitions, time zone, currency, approval state, and reporting delay. Keep event time distinct from the time a system received or displayed the event.
A lower count can mean a broken handoff, a different event definition, or simply a conversion that has not arrived yet. A higher count can include duplicates or status updates. Investigate with permitted event-level evidence rather than deciding which total looks better.
Before retirement, confirm exports, access, retention obligations, outstanding callback handling, and any remaining outbound event ownership. Keep authorized records needed for reconciliation without retaining personal data indefinitely.
Frequently asked questions
Can I change the network postback URL and move all old conversions?
Not safely by assumption. A new tracker may not recognize old IDs. Obtain a documented transition design for the network's callback limits and the old click cohort before changing the destination.
Should both trackers send conversions during migration?
Not automatically. Define one authorized sender per event and destination unless a documented, verified design establishes safe deduplication. Mirroring receipt is not the same as safe duplicate ad-platform delivery.
Does an imported campaign preserve reporting history?
Only if the vendor explicitly supports that history and the relevant attribution behavior. Configuration import, page import, and historical reporting are separate capabilities.
How long should I keep the old tracker active?
There is no universal duration. Base it on outstanding clicks, conversion and adjustment windows, data obligations, callback constraints, and the agreed retirement evidence.
Can I roll back without losing new-tracker conversions?
Only if the transition retains a resolvable path for IDs already issued by the new tracker. Moving future traffic back does not move those IDs or their delayed conversions into the old system.
Where Tracked is today
Tracked's available core combines hosted HTML/ZIP pages, page editing, configured routing, conversion postbacks, reports, and journeys. This checklist does not claim an automatic importer, history transfer, or universal outbound conversion integration. Account terms and provider-specific setup still need confirmation; in-development capabilities do not become available through migration.
Start free to evaluate one supported campaign workflow before planning a paid-traffic move. Keep your existing click and callback obligations separate from that evaluation.