The Day I Almost Deleted the Analytics Identifier

Automotive

While adding automatic filenames to an email-template builder, I looked at another identifier in the interface and thought it had become redundant.

The new filename already described the template and creation time. Why keep a second field with a value such as:

ICG-SOTW_11.09

Removing it would have broken analytics.

Two identifiers that looked alike

The confusion came from two strings carrying similar campaign language while serving different systems.

Campaign identifier

The campaign identifier grouped analytics:

ICG-SOTW_11.09

Every tracked link and event for that campaign used the same value. It answered questions such as:

  • How many recipients clicked?
  • Which vehicles received attention?
  • How did the campaign perform as a whole?

Filename

The generated filename identified one saved artifact:

SOTW-8_1109_1545.html

It answered different questions:

  • Which revision is this?
  • When was it generated?
  • Is this the single-vehicle or multipicture template?
  • Which file is newest?

Several files could belong to one campaign:

SOTW-1_1109_0930.html
SOTW-1_1109_1415.html
SOTW-8_1109_1545.html

They were separate revisions but shared one analytics identity.

Why combining them would have been wrong

If the filename became the campaign identifier, every saved revision would fragment the analytics:

Revision A → one campaign in Matomo
Revision B → another campaign
Revision C → another campaign

The reporting system would no longer show the campaign as a coherent effort.

If the campaign identifier became the filename, saving another revision would overwrite the earlier file or require an unrelated suffix. The storage system would lose a clean revision identity.

The duplication was only visual. Semantically, the fields belonged to different bounded contexts:

  • Analytics cared about continuity.
  • File storage cared about uniqueness.

The interface was partly at fault

The user’s question was reasonable because the UI did not explain the distinction.

A value displayed without a label or consequence invites removal. “Campaign ID” was not enough. “Analytics campaign identifier” was clearer because it described the consumer.

Good labels should help answer:

  • Who uses this value?
  • Does it remain stable?
  • What changes if I edit it?
  • Is it identifying a business activity or a saved artifact?

The fix was not merely to keep both fields. It was to make their roles visible.

A practical example

Consider one dealership campaign:

Campaign: Inside Car Guys — Sale of the Week
Analytics identifier: ICG-SOTW_11.09

During production, the team might save:

SOTW-1_1109_0930.html   First draft
SOTW-1_1109_1415.html   Price correction
SOTW-8_1109_1545.html   Final multipicture version

The filenames preserve the work’s evolution. The campaign identifier allows all delivered variants to roll up into the same report.

Keep The Two Contexts Separate

Identifiers should be designed around identity boundaries, not around how similar their values look.

The same pattern appears elsewhere:

  • A database row ID is not a public order number.
  • A media asset ID is not its filename.
  • A deployment version is not a marketing release name.
  • A person is not their email address.

Using one value for several identities can feel simpler at first. It usually transfers complexity into migrations, reporting, and edge cases.

The near-deletion also reinforced a useful maintenance habit: before removing a field, trace both its readers and writers.

Search where it is:

  • Created
  • Stored
  • Rendered
  • Sent to external systems
  • Used in reports

The interface showed one field. The application architecture showed a contract with Matomo.

What changed afterward

I kept both identifiers and continued improving their formats independently.

The campaign identifier became stable enough to connect saves and analytics. The filename gained timestamp-based uniqueness for proofs and revisions.

More importantly, the distinction became part of the documentation.

The two-minute conversation that prevented the deletion was not a failure of the user or the developer. It was evidence that the system had hidden an important concept.

Sometimes apparent duplication is accidental complexity. Sometimes it is separation of concerns doing exactly what it should. The only way to know is to follow the data far enough to see what it means.