What Not to Rebuild

The default is to carry everything

Faced with a migration, the instinct is to reproduce what exists, item by item, until the new thing matches the old one.

That feels responsible and it means an afternoon spent rebuilding things nobody has looked at since they were configured.

Analytics setups accumulate: a goal added for a campaign in 2019, a filter somebody created and forgot, a custom report built for a question nobody asks now.

A migration is the one moment when carrying each of those forward requires a positive decision, which makes it the cheapest opportunity to stop.

The test

Two questions per item, and both have to be yes.

Has anybody looked at this in the last year.

Did anything change as a result.

An item failing the first is dead. An item passing the first and failing the second is interesting rather than useful, which is a comfortable place for a metric to live and not a reason to rebuild it.

Applied honestly, that test removes most of what is in a typical small business setup.

Where you cannot remember whether anybody looked, that is an answer.

What usually fails it

• Goals that have never fired.
• Goals for pages that no longer exist.
• Custom reports built for one question years ago.
• Segments nobody can explain.
• Time and page-depth measurements.
• Campaign tags from finished campaigns.

The first two are worth checking rather than assuming, since a goal recording nothing for two years is usually a goal pointing at a page that was renamed during a rebuild.

Check what fired before deciding

The step that turns opinion into evidence, and it takes ten minutes.

Open your goal or conversion reporting for the last twelve months and look at the totals.

Anything at zero is not a candidate for rebuilding, it is a candidate for understanding, since it either never worked or measures something that stopped happening.

Then look at the numbers that are not zero and ask which of them you have ever quoted to anybody.

That second list is what to rebuild, and it is usually two or three items.

The rest can be left where they are, in a system that will keep them for a while yet, which is a reversible decision rather than a deletion.

A worked example

A business set aside a day to rebuild their analytics configuration and started by listing what existed.

They found seven goals, four custom reports, two segments, and a set of campaign tags.

Checking the last year showed three goals had fired, one of which was the contact form and two of which were duplicate configurations of the same thing from different eras.

None of the four custom reports had been opened in over a year, and nobody could say what one of the segments was for.

They rebuilt two conversions and nothing else.

The day they had set aside took under an hour, and the new configuration was something a person could read and explain, which the old one had not been for years.

Simpler is not merely faster to build

Worth saying, since the argument here is usually made as one about effort.

A configuration with two conversions produces a number somebody can check against reality. One with eleven produces a number nobody can interpret.

A report with five figures gets read. One with twenty gets glanced at.

So the reduction is not a compromise made for time, it is the better outcome on its own terms, and the migration is simply what makes it easy to do.

Businesses that rebuild faithfully arrive in the new system with the same setup nobody understood, having spent a day to get there.

Keep the record of what you dropped

The one piece of documentation worth producing.

Write a short list: what existed, what you rebuilt, and what you left behind with a word about why.

That takes ten minutes and answers the question somebody will ask in eight months, which is whether a particular thing used to be measured.

It also protects the decision, since without it the absence looks like an oversight rather than a choice.

Where you dropped something that turns out to matter, the record tells you what it was and it can be rebuilt in minutes.

The same applies beyond analytics

A brief extension, because the principle is more general than the occasion.

Any migration is a filter: a new site, a new host, a new accounting system, a new phone.

Each is a moment when everything has to be justified rather than inherited, and most of them are handled by copying everything across.

Pages nobody reads, plugins nobody uses, subscriptions nobody opens, and documents nobody has needed all get carried through migrations for years.

Applying the same two questions at those moments is worth more than the analytics case on its own.

The counter-case

Dropping things has a real cost when the judgement is wrong.

Some measurements are configured for an annual or seasonal question, so a year of no attention is not evidence of no value, and checking a twelve-month window can miss something used every January.

There are also obligations: a business reporting to a funder, a franchise, or a client may be required to produce a particular figure regardless of whether it informs anything.

And a metric nobody has used may simply be one nobody knew existed, which is an argument for a conversation rather than a deletion.

Ask before dropping anything somebody else relies on, keep the record, and be willing to rebuild something you removed.

The hour

1. List everything configured in the old setup.
2. Check which goals fired in the last year.
3. Ask who looked at each report.
4. Ask what changed as a result.
5. Rebuild what passes both and nothing else.
6. Ask before dropping anything somebody else uses.
7. Write down what you left behind.

Step two is the evidence, and a zero against a goal is a finding rather than a reason to reproduce it carefully in a new system.

Finding the equivalents worth having is covered in reports that no longer exist.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.