How Mepal sees which customers drive email performance

Mepal could see how an email campaign performed overall. What the team could not see was which customer groups were driving the result.

Using information already in Deployteq, Mepal now compares results for groups such as new customers, recent buyers and loyal customers in SEINō.

The setup did not require a new data system.

Mepal

Consumer products

Marijn van de Bree

Email Marketeer & CRM Specialist

An overall click-through rate can hide two very different stories. A campaign may look average because one customer group responds strongly while another barely engages. For Mepal, that meant campaign-level reports were useful, but not enough to decide how to make its email program more relevant.

The question behind the campaign total

Marijn van de Bree, Email Marketeer & CRM Specialist, wanted to know how newsletters performed for different kinds of customers. Were returning customers responding differently from new ones? Did customers who bought recently click differently from those whose last order was more than a year ago? Which RFM segments were driving a result up or down?

Much of the information needed to answer those questions was already in Deployteq. Mepal had customer attributes and purchase history, but the team could not yet use that context as consistent dimensions in its SEINō reports.

Implementation time: Less than a day
Customer context in historical reports: Preserved at send time

Turning existing data into reporting dimensions

Mepal and SEINō identified the customer context that would make the reports more useful: RFM segment, time since first and last purchase, subscription age and whether someone had bought a personalized MyMepal product.

Deployteq calculates those values when an email is sent and adds them as metadata to the send events SEINō receives. SEINō maps the metadata to custom dimensions, so the team can filter and compare campaigns by those customer groups. The setup uses information and templating capabilities already in Deployteq; it did not require a new customer database or middleware project.

For dates, Mepal uses meaningful ranges rather than a separate value for every date. A customer can, for example, be grouped by how many months have passed since their last purchase. That makes the groups easier to compare and keeps the reporting manageable.

Keeping the right context with each send

The customer context is captured at send time. If someone was a recent purchaser when they received a campaign, that campaign keeps the “recent purchaser” context in its historical report even if the customer’s status changes later. Mepal can therefore compare past campaigns using the audience context that applied when each message went out.

The team also added a hashed value to its email links’ UTM parameters, including information that distinguishes one send from another. This helps connect website sessions to the corresponding email send. Together with the send metadata, it lets Mepal investigate what different customer groups do after they click, not just whether they clicked.

A stronger starting point for segmentation

The source case reports that the setup was implemented in less than a day, with SEINō helping prepare the Deployteq template logic and Mepal making the final template changes. The result is a reporting view the CRM team can use to see which groups contribute to a campaign’s performance and where a more targeted approach may help.

For Marijn’s team, the gain is a better question after every send: not only “How did this campaign perform?” but “Which customers responded, and what should we do differently for them next time?”

For the implementation steps and Smarty examples, read how to report on customer segments with Deployteq metadata and SEINō.

Questions to take into your next CRM review

Which customer groups are lifting or lowering a campaign's overall result?
Does engagement change with time since the last purchase or subscription age?
Which segments click through but do not convert on the website?

These are questions to investigate with your own data, not a claim that another team will see the same results.