Starting Over With a New Pixel: What Actually Carries Over and What You Lose

Something has gone wrong. The ad account was disabled, or the dataset was restricted, or performance has been bad for long enough that the account itself starts to feel cursed. So you build a new one: new ad account, new pixel, same products, same creative, and the hope that whatever was weighing the old setup down stays behind. It is worth knowing which half of that hope is realistic before you spend a month finding out.

What a new dataset genuinely resets

Start with the honest upside, because there is one.

A new dataset has no event history, which means no accumulated signal about who converts. If your old dataset had been fed months of mis-specified events, if the wrong action was being sent as a Purchase, or if a long-running duplication problem had inflated everything, then starting clean does remove that. You are not dragging a corrupted signal forward.

It also resets anything built on top of that history. Website custom audiences, lookalikes seeded from them, and exclusion audiences are all gone, which is a loss, but if the underlying events were wrong then those audiences were wrong too.

That is the real case for a rebuild, and it is narrow: it applies when the data itself was bad. It does not apply when the data was fine and the account was simply unlucky.

What follows you to the new pixel

Here is where the plan usually comes apart. A dataset ID is an identifier, not an identity. Several of the things people are trying to escape are not attached to it.

• Your domain. If a classification or a restriction was driven by what your website says, the new dataset points at the same website. Nothing that was read before has changed.
• Your business portfolio. Assets created under the same portfolio are associated with it. A fresh dataset in the same portfolio is not an unrelated stranger.
• Domain verification and event configuration. The verified domain and its event priority ordering are properties of the domain, not of the dataset. You will be configuring the same eight events against the same verified domain.
• Whatever actually caused the problem. This is the one that matters. If you never established why the account was disabled or the dataset restricted, a new pixel is a change of scenery, not a fix.

The practical version: a rebuild helps when the problem lived in the data. It does not help when the problem lived in the site, the policy assessment, or the business entity.

Can you feed the old data into the new pixel?

This is the question everyone asks, usually phrased as "we still have all of it in our own system, can we just push it in to warm the pixel up?" The answer is mostly no, and the reason is a specific documented limit rather than a policy judgement.

The Conversions API will not accept arbitrarily old events. Meta's documentation is explicit that the event_time on a server event can be up to seven days before you send it. Events stamped older than that are not a slow import, they are refused.

So the mental model of "replay last year's purchases into the new dataset so it starts smart" does not survive contact with the API. You can send the last week. You cannot send the last year. Whatever history you have in your own database stays in your own database as far as the pixel is concerned.

There is one carve-out worth knowing: offline and physical store events, sent with a physical store action source, have a much longer upload window measured in weeks rather than days. That is genuinely useful if you have in-person transactions to reconcile, and it is covered in more depth in the offline conversion tracking guide. It does not, however, let you backfill a year of ecommerce purchases.

What you can actually carry across

Not everything is lost, and the things that survive are worth collecting deliberately rather than discovering later.

1. Customer lists. Your own CRM or order database is yours. A customer file audience built from it can be uploaded to the new setup, and a lookalike can be seeded from that. This is the single most valuable thing that transfers, and it is the one people forget because they are thinking about pixel data rather than their own records.
2. Creative and the knowledge of what worked. Obvious, but worth stating: the winning angles, hooks and formats are not account property. Rebuilding with proven creative is meaningfully faster than rebuilding blind.
3. Everything you learned about your funnel.Which event predicts a real buyer, what your actual conversion lag is, which audiences never worked. That knowledge shortens the new account's exploration considerably if you write it down instead of trusting memory.
4. Recent events, within the window. The last seven days can be sent. It is not nothing, particularly if you are rebuilding while the old setup is still receiving traffic.

How long the new account takes to pick up

The honest answer is that it depends on your conversion volume, and the number that governs it is well known. Optimisation needs enough recent conversions of the event you have chosen before delivery stabilises, and the commonly cited threshold is around fifty conversions per week per ad set.

Divide your realistic weekly conversion count into that and you have your answer. An account doing two hundred purchases a week will stabilise quickly. An account doing fifteen will spend a long time in an unstable state, and that is not a fixable scheduling problem, it is arithmetic.

If you are in the second group, the single most useful decision you can make is to optimise for a shallower event that actually produces volume, and move deeper once the numbers support it. That trade is covered in choosing the right optimisation event. Rebuilding onto a deep, rare event is how new accounts stall for a month.

When starting over is the right call

There are real cases. It is worth naming them so the decision is not purely emotional.

• The ad account is permanently disabled and the appeal has genuinely been exhausted. At that point there is no account to preserve.
• The old dataset was demonstrably recording the wrong thing and had been for long enough that every audience built on it is suspect.
• The business itself has changed, different domain, different products, different buyer, so the old history would be misleading even if you kept it.

Notice what those have in common: each one establishes that the old data is either unavailable or actively wrong. None of them is "this account feels unlucky".

Before you pull the trigger

A short checklist, in the order that saves the most money.

1. Write down why you believe the old setup is unrecoverable. In a sentence. If you cannot, you are not ready to rebuild, you are frustrated.
2. Export your customer list first. Before touching anything. This is the asset that transfers and it is the one people lose by doing things in the wrong order.
3. Record the current configuration. Which events exist, which are prioritised, what the verified domain is, what each event is worth. You will be recreating this and you will not remember it accurately.
4. Fix the cause on the site before the new dataset sees it. If a policy assessment drove this, change the pages first. Otherwise you are introducing a clean dataset to the same material that got the last one flagged.
5. Expect the learning cost and budget for it. Plan for a few weeks of worse numbers rather than treating them as evidence the rebuild failed.

Run both for as long as you can

If the old setup is restricted rather than deleted, the instinct is to tear it out on the day the new one goes live. Resist that where the platform allows it.

Keeping the old dataset receiving events costs nothing and buys you two things. The first is a reference: when the new dataset reports a number, you have something to compare it against, and "both are seeing roughly the same volume" is a much faster way to confirm the new install is correct than reasoning from first principles. The second is that if the restriction is lifted during your rebuild, which does happen, you have not destroyed the asset you were trying to recover.

The thing to be careful about is firing both into the same campaigns without thinking it through, because you can end up double counting and making both datasets look wrong. Keep them separate: one receives events for reference, the other is the one your campaigns actually optimise against.

When you do finally decommission the old one, do it deliberately rather than by deleting things. Write down what it was, what it was receiving, and what you concluded. The next person to inherit this account, possibly you in eight months, will want to know why there are two datasets and which one is real.

The thing worth doing either way

Whichever path you take, the underlying lesson is the same: almost everybody in this situation discovered the problem long after it started. The dataset was restricted, or the events stopped arriving, and the first signal was a run of bad performance rather than a notification. By the time it is understood well enough to consider a rebuild, weeks of spend have usually gone through a setup that was not recording properly.

A new pixel does not change that dynamic. It just resets the clock on it. The thing that actually reduces the cost of this class of problem is noticing it in hours rather than weeks, and that is a monitoring question rather than a rebuilding one.