Audience Segmentation and Personalisation
Segments built from behaviour and value rather than guesswork, personalisation that degrades gracefully when data is missing, and holdout tests to show whether any of it helps.
Most teams segment by whatever field is easiest to filter on, then personalise with a first name and call it done. Real gains come from audiences defined by behaviour and value, content that changes for reasons a customer would recognise, and testing that shows whether the extra effort earned anything. Marketing Cloud segmentation and personalisation work best when the data, the rules and the measurement are designed together.
GeekMidst helps marketing and CRM teams define useful segments, build them in Marketing Cloud Engagement or Data Cloud (now branded Data 360), and personalise content in a way that is maintainable.
The questions we help you answer
- Which customer groups behave differently enough to deserve different messages?
- Where should each segment be built: SQL in Marketing Cloud, filters, or Data Cloud?
- How much personalisation is worth maintaining, given the data you actually have?
- How will you know whether a segment or a personalised block improved results?
What we deliver
Segment design
A documented segment framework covering lifecycle stage, purchase behaviour, engagement and value, with clear rules and owners for each segment.
SQL audiences
Query Activities in Automation Studio that build segments on a schedule, with deduplication and exclusion logic.
→Data Cloud segments
Segments and calculated insights on unified profiles, activated to Marketing Cloud for sends and journeys.
→Content personalisation
Dynamic content blocks, AMPscript lookups and product or offer logic with fallbacks for missing data.
→Measurement design
Holdout groups, baselines and reporting so each segment and personalisation choice can be judged on evidence.
→A worked example: repeat buyers in the last 180 days
A common first segment is customers who have bought at least twice recently. In Marketing Cloud Engagement this is usually built with a SQL Query Activity that writes to a target data extension on a schedule.
Assumptions: a Customers_DE data extension keyed on SubscriberKey, an Orders_DE data extension with one row per order, and a target data extension Repeat_Buyers_180D with SubscriberKey as its primary key and the query set to overwrite.
SELECT
c.SubscriberKey,
c.EmailAddress,
COUNT(o.OrderID) AS OrderCount,
MAX(o.OrderDate) AS LastOrderDate
FROM Customers_DE c
INNER JOIN Orders_DE o
ON o.SubscriberKey = c.SubscriberKey
WHERE o.OrderDate >= DATEADD(DAY, -180, GETDATE())
GROUP BY c.SubscriberKey, c.EmailAddress
HAVING COUNT(o.OrderID) >= 2Subscription status is still checked at send time against All Subscribers and any publication lists, but it is good practice to exclude known suppressions in the query too, so audience counts match what will actually be sent. If several sources feed the order table, deduplicate it first, typically with ROW_NUMBER() partitioned by order ID.
Personalisation in layers
We think about personalisation as layers, adding each one only when the data supports it:
- Relevance by segment. Different content blocks for clearly different groups, using dynamic content rules.
- Attribute personalisation. Names, locations, tier or account details, always with a fallback.
- Behavioural content. Recently viewed or purchased categories, using lookups against data extensions refreshed on a known schedule.
- Predictive features. Einstein features such as send time optimisation or content selection, where your edition includes them and you have enough data for them to be useful.
Each layer adds maintenance. A segment that nobody can explain, or a block that depends on a feed that breaks monthly, costs more than it returns.
Measuring honestly
For any new segment or personalised element we agree a holdout or control group before launch, record a baseline, and compare like with like after a set period. Open rates are a weak measure because of mail client privacy features, so we prefer clicks, conversions and downstream revenue where they can be tracked.
How the work runs
- 01
Data and goals review
Look at the data available, its freshness and quality, and the commercial goals each segment should support.
- 02
Segment framework
Agree a small set of segments with definitions, priority rules for overlaps and an owner for each.
- 03
Build
Create the queries, filters or Data Cloud segments, plus refresh schedules and exclusion logic.
- 04
Personalise
Add dynamic content and AMPscript to templates with fallbacks, and test with edge-case records.
- 05
Measure and refine
Run holdouts, review results with your team and retire segments that do not earn their place.
Questions we hear
Should we build segments in Marketing Cloud or Data Cloud?
How many segments should we have?
What happens when personalisation data is missing?
Can you personalise journey emails as well as campaigns?
Do we need consent for personalisation?
Plan segments and personalisation that pay off
Tell us what data you have and what you want customers to do next. We will suggest a practical starting set of segments and how to test them.
