The Day I Almost Deleted the Analytics Identifier

Automotive

Archive note, November 2025: This came from the
automotive BDC template system, where generated email files and Matomo
campaign tracking evolved side by side.

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.

The broader design lesson

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.