The Email Module Audit: Finding What Actually Earns Clicks

An email module audit is a review of every reusable block in your mailer library, in which you ask what job each one does, whether it earns clicks, and whether another module already does the same thing. Each module then gets one of three verdicts: keep, merge or cut. That's the whole idea. The rest of this post is how I run it, drawn from the ixigo Mailer Design System work.

For context, the ixigo email system took click-through rate from 4.2% to 18%. I won't claim an audit alone did that, because a system has many moving parts. But deciding which modules deserved to exist was a big part of the thinking, and it's the part you can copy.

The short version: four passes

Inventory. List every module that has shipped, with a screenshot and the campaigns it appeared in.
Name the job. Write one sentence per module on what it asks the reader to do.
Read the clicks. Look at how each module performs where it actually appeared, not just overall campaign numbers.
Decide. Give each module a keep, merge or cut verdict, and write down why.

Nothing here needs special tooling. A spreadsheet and your email platform's click reports are enough.

Pass 1: Inventory everything that has shipped

Start from what went out, not from what the design file says exists. Libraries drift. Someone adds a one-off hero for a campaign, someone else duplicates a card with slightly different padding, and a year later nobody remembers which version is canonical.

Pull the last several months of sends and screenshot each one. Then mark every distinct module you see. If two modules look nearly identical, list them separately for now. You'll deal with that in the merge pass.

Pass 2: Name the job of each module

This is the step people skip, and it's the one that makes the rest work. For each module, write a single sentence in the form: this module exists so the reader can ___.

Good answers are specific: see the main offer and tap through, compare a few options quickly, pick up where they left off. Weak answers are things like add visual interest or fill space. If you can't name the job, that's already a signal. A module without a job is a cut candidate.

You'll also notice that several modules share the same job. Group them. Those groups are where merging happens.

Pass 3: Read clicks per module, with some care

Now look at click data by module, not just by email. Most platforms can show clicks by link, and if your links are labeled sensibly, you can map them back to modules.

A few cautions so you don't fool yourself:

Position matters. A module near the top will get more clicks than the same module near the bottom. Compare modules in similar positions, or note the position next to every result.
Audience matters. A module used only in a campaign for a highly engaged segment will look better than it is.
Sample size matters. If a module appeared in only one or two sends, treat the result as a hint, not a verdict.
Clicks aren't the only signal. A module that supports the main call to action, even with few clicks of its own, may be doing useful work. Check before you cut it.

Here's a simple column layout I'd use for the sheet:

Pass 4: Decide keep, merge or cut

With the sheet filled in, each module gets a verdict using a few plain rules.

Keep

Keep a module when it has a clear job, nothing else in the library does that job as well, and its click behavior holds up across several sends. Keepers become the core of the system. Give them the best documentation.

Merge

Merge when two or more modules share a job. Pick the strongest one as the base, then absorb the useful differences as options inside it, such as a layout variant or an optional line of supporting text. The goal is fewer modules with sensible flexibility, not a single module with twenty toggles. If a merged module needs a manual to use, you've gone too far.

Cut

Cut when a module has no clear job, duplicates a better one, or consistently pulls attention away from the main action without earning its own clicks. Cutting is uncomfortable, especially for modules someone loved designing. Write the reason in the sheet anyway. It makes the decision easier to explain later.

Why this works for a design system, not just a cleanup

A mailer library is a set of choices you hand to other people. Every extra module is another decision for whoever builds the next email, and more room for inconsistent results. Fewer, clearer modules mean faster builds and a more predictable experience for the reader.

It also changes how you design new modules. Once you've named jobs, any new request gets the same question: which job does this serve, and why can't an existing module do it? Sometimes the answer is a real gap and you add something. Often it isn't, and you've saved the library from growing.

Common mistakes to avoid

Cutting purely on click counts. Context matters, so read position and audience before judging.
Merging by appearance only. Two modules that look alike may do different jobs. Merge on job, not on looks.
Auditing once and forgetting. Put a small recurring review on the calendar, even a short one.
Skipping the reasons. A verdict with no written reason gets reversed the next time someone has an opinion.

Run it on your own library this week

Open a spreadsheet, list the modules from your last batch of sends, and write the one-sentence job for each. Even if you stop there, you'll probably spot overlaps you hadn't noticed. Then add the click data and make your keep, merge and cut calls.

If you want to see how this played out in practice, the ixigo Mailer Design System case study on this site shows the work behind the numbers. And if you're hiring for senior marketing design and want someone who thinks in systems, I'm always happy to talk.