How to report on customer segments with Deployteq metadata and SEINō

A campaign’s overall click-through rate tells you how the audience responded as a whole. To understand why, you may need to compare the customer groups inside that audience: recent buyers, customers who have not ordered for a while, or people in different RFM segments.

If those attributes already exist in Deployteq, you can pass them to SEINō with your email events and use them as reporting dimensions. This guide walks through the approach used in the Mepal client case, including the Smarty code for grouping customers by time since their last purchase.

Start with the questions you want to answer

Mepal wanted to see which customer groups were contributing to campaign results. Its measurement plan included five dimensions:

Dimension	Example question
RFM segment	How did our most valuable customers respond?
Time since first purchase	Do newer customers engage differently from established customers?
Time since last purchase	Which groups are still clicking after a long period without ordering?
Subscription age	Does engagement change as a subscriber relationship develops?
Personalized-product customer	Do customers who bought personalized products respond differently?

Choose the dimensions and categories before adding code. In Mepal’s setup, the team used its RFM model and analysis to define useful date ranges, then cleaned up older customer records that did not have valid values.

You will need access to the relevant customer fields and email template in Deployteq, an existing Deployteq integration with SEINō, and a plan for mapping the metadata fields to dimensions in SEINō. Website comparisons also require your web analytics integration and campaign tracking to be configured.

Add customer context to the metadata

Deployteq’s template can read customer attributes and calculate values while rendering an email. Assign the values to the $metadata array so they are included with the events passed through the Analytics API.

For example, once the variables below have been populated by your template:

<!--{$metadata['seino_rfm'] = $rfm}-->
<!--{$metadata['seino_last_bucket'] = $last_order_bucket}-->
<!--{$metadata['seino_first_bucket'] = $first_order_bucket}-->
<!--{$metadata['seino_subscribed_bucket'] = $subscribed_bucket}-->
<!--{$metadata['seino_mymepal_kopers'] = $mymepal_kopers}-->

These names come from the Mepal example. Use names that make sense for your own attributes, and keep them consistent between the template and the SEINō mapping. The assignments pass existing variable values; they do not calculate the segments themselves.

Calculate time since the last purchase

Here is the complete example for one dimension. It reads the last order date, calculates the number of completed months since that order, assigns a reporting bucket and passes the bucket to SEINō.

Replace E29 with the field that holds the last order date in your Deployteq environment.

<!-- Current date -->
{{$current_day = "{{currentdate|@strtotime format='%Y-%m-%d'}}"}}
{{$current_y = $current_day|date_format:"%Y"}}
{{$current_m = $current_day|date_format:"%m"}}
{{$current_d = $current_day|date_format:"%d"}}

<!-- Read last order date -->
{{customer_option|htmlentities field='E29' assign='last_order'}}

{{if $last_order}}

    {{$last_order = $last_order|@strtotime}}
    {{$last_y = $last_order|date_format:"%Y"}}
    {{$last_m = $last_order|date_format:"%m"}}
    {{$last_d = $last_order|date_format:"%d"}}

    <!-- Calculate months since last purchase -->
    {{assign var=months_since value=(($current_y - $last_y) * 12) + ($current_m - $last_m)}}

    <!-- Correct if the current month has not yet fully passed -->
    {{if $current_d < $last_d}}
        {{assign var=months_since value=$months_since-1}}
    {{/if}}

    <!-- Convert to reporting bucket -->
    {{if $months_since < 6}}
        {{$last_order_bucket = "0 - 6 months"}}
    {{elseif $months_since < 9}}
        {{$last_order_bucket = "6 - 9 months"}}
    {{elseif $months_since < 12}}
        {{$last_order_bucket = "9 - 12 months"}}
    {{elseif $months_since < 15}}
        {{$last_order_bucket = "12 - 15 months"}}
    {{else}}
        {{$last_order_bucket = "15 - 24+ months"}}
    {{/if}}

{{else}}

    {{$last_order_bucket = "No orders"}}

{{/if}}

<!-- Send metadata to SEINō -->
<!--{$metadata['seino_last_order_bucket'] = $last_order_bucket}-->

This standalone example uses the metadata key seino_last_order_bucket. The earlier multi-dimension example uses seino_last_bucket for the same variable. Choose one key and use that key in your SEINō mapping.

The calculation first finds the difference between the order month and the current month. It then subtracts one month if the current day of the month comes before the order’s day. That keeps a customer from moving into the next group before the corresponding day has arrived.

For example, an order on December 30 is still five completed months old on June 29. On June 30, the calculation reaches six months and moves the customer into the next bucket.

The labels are shorthand for the conditions in the code:

Label	Completed months
0–6 months	Fewer than 6
6–9 months	At least 6, fewer than 9
9–12 months	At least 9, fewer than 12
12–15 months	At least 12, fewer than 15
15–24+ months	15 or more, with no upper limit
No orders	No last order date is present

Adjust the ranges to your purchase cycle. Check that your source dates are valid and do not fall in the future before using them in the calculation.

Map the fields in SEINō

Once the metadata is arriving, map each field to a custom dimension in SEINō. The dimensions can then be used to filter and compare results in dashboards, Data explorer, reports and AI Insights.

Start with a campaign you know well. Compare its overall result with the same result split by one dimension, such as time since last purchase. Check that the categories and counts make sense before adding further dimensions.

Because the values are calculated when the email is sent, they describe the customer’s context for that send. A recipient who was a recent buyer for an earlier campaign stays in that campaign’s recent-buyer group even if their last purchase becomes older later. This preserves the context you need when comparing historical campaigns.

That distinction also matters when selecting a reporting period. See Send Date vs Event Date for how SEINō groups sends and later activity in time.

Connect the comparison to website behavior

Mepal also added a hashed value to utm_term, using the send date and the customer bucket as its input:

{{$utm_term = "{{$current_y}}{{$current_m}}{{$current_d}}-{{$last_order_bucket}}"}}

{{$globals.utm_term = "{{$utm_term}}"|md5}}

This example uses the date variables and $last_order_bucket calculated above. It sets the template’s global utm_term value; your link configuration must include that value in the URLs sent to recipients. In Mepal’s template, URL parameters were already configured, so the team added this value to the existing setup.

The date adds context that helps distinguish recurring sends whose other UTM values might be reused. The hash is shared by recipients with the same date and bucket; it is not a unique recipient identifier. Two sends on the same date with the same bucket also produce the same value, so keep the other campaign and send identifiers needed by your tracking setup.

With the metadata and website tracking mapped together, you can investigate which groups click through, which generate attributed revenue, and where engagement does not lead to conversion. The hash itself does not contain readable segment labels; it works as part of the configured matching between email and website data.

Check the setup with a small send

Before rolling the template out across campaigns, check a few known customer records: a recent order, a record on a bucket boundary, an older order and a record with no orders. Confirm that the expected metadata arrives in SEINō and that the dimension labels match your measurement plan.

For website reporting, inspect an actual link from a test email, follow it through to your analytics data and verify the matching in SEINō. This catches a missing URL parameter or mismatched field name before it affects a wider report.

The result is a repeatable way to bring customer context into campaign analysis. Read how Mepal uses it to see how these dimensions support the team’s move toward more relevant customer segments.