Engagement Segmentation Built in Your Warehouse

Most files we are handed have 30 to 45 percent of addresses with no click, session or purchase in the last 180 days, and until those addresses stop receiving mail, no segmentation scheme built on top of them will change a number you care about. So the first segment we define is the one that stops receiving. Everything else is built on that decision. Where segments live: In your warehouse, not in the sending platform's audience builder. We write the definitions as SQL against Snowflake, BigQuery or Postgres and sync them out with Hightouch, Census or the platform's list API into Iterable, Braze, Customer.io or Klaviyo. The reason is not tidiness. A platform-native segment is invisible to your analysts, cannot be joined to revenue, and breaks quietly when a tracking plan changes. A segment defined in the warehouse is reviewable in a pull request and testable before it reaches anyone. What counts as engagement: Not opens. Apple Mail Privacy Protection prefetches images for every message it renders, which on the files we see means 40 to 60 percent of the list reports an open nobody performed. We build recency on clicks, authenticated sessions, app opens attributed through AppsFlyer or Branch, and completed purchase or donation events. For app clients this usually means the email engagement grade and the in-app activity grade are two separate columns that are allowed to disagree, because a daily active user who ignores email is not a lapsed customer and should not be treated as one. What you get: A segment dictionary: each segment named, defined in SQL, with the population on the day it was cut and the decay we expect over the following quarter. A suppression policy with the thresholds written down and the argument for each threshold, so the next person to question them has something to argue with. A mapping from segment to sending stream, so nobody has to guess which audience a new campaign belongs to. And a verdict on the segments you already have, including the ones we recommend deleting. Hebrew and mixed-language files: For Israeli lists we segment on a stored language preference rather than inferring it from the email domain or the browser locale, both of which are wrong often enough to matter on a donor or subscriber file. The dictionary carries the RTL variant of every stream that has one. What this is not: Not persona work. No named archetypes, no stock photography, no wheel diagram. Not a campaign build — the flows that consume these segments are separate work, and we would rather you take the dictionary to your own team than buy the build from us by reflex. Not a data cleanup project either: if your events do not distinguish a human click from a security scanner's fetch, we will tell you in week one and stop, because segmenting on bad events is worse than not segmenting. Who should not buy this: Anyone whose file is under roughly 50,000 addresses. At that size the segmentation that pays is two or three splits you can reason about yourself, and paying us is waste. Anyone who intends to keep mailing the dormant tail because it still produces a small absolute number of conversions — that position is coherent on its own terms and we are not the shop that will execute it. Anyone whose list was bought, rented or appended. How it runs: Two weeks reading your data before we propose anything: the event schema, the last six months of sends, Google Postmaster Tools where the domain is large enough to have data, and the platform's own bounce and complaint records. Then a working session with whoever owns analytics. Then the dictionary. We do not write segments for data we have not seen.