tracking-change-controllisted

# Tracking change control Changing tracking on an account that is spending costs money before it saves any. The work is not the code. It is the order. ## What actually resets Changing which event a campaign optimises to points it at an event with no history. Expect a period of degraded efficiency while it relearns — commonly framed as one to two weeks, but treat that as a convention and check the platform's current stated learning requirement in conversions per week. Adding a new event alongside an existing one does not reset anything. That asymmetry is the whole basis of the sequence below. ## The sequence 1. **Add, do not replace.** Fire the new server events alongside everything already running. Nothing is pointed at them yet. 2. **Verify one real transaction** in the platform's test view: it arrives, it deduplicates, it carries the right value and currency. 3. **Let history accumulate.** The new event needs volume before a campaign can optimise to it. 4. **Reconcile it** against the ledger for a week before anyone depends on it. 5. **Switch one campaign.** Not all of them. 6. **Hold everything else still** for the relearning period. 7. **Retire the old event** only after the new one has proven out. ## Rules that survive contact **Never migrate during a period when volume has to hold.** A launch, a seasonal peak, a month with a committed target. The relearning cost is real and it lands exactly when you cannot absorb it. **Never change tracking and creativ