I usually like to give you something you can test and measure right away. This post is a little different. It is more “foundational principle” than “run this A/B test,” but it will save you headaches for years if you get it right early.

---

---

I am knee-deep in updating our data dictionary at work right now, so this is very front of mind:

When you are creating or revisiting your CRM / lifecycle database, pass raw data. Do your calculations in your CRM platform.

That is it. That’s the whole tip. But let’s explore it a little more, because it matters a lot.

What “Raw Data” Actually Means

When I say “raw data,” I mean the facts, not someone’s interpretation of the facts.

• Raw: reward_expiration_date = 2025-12-31
• Not raw: rewards_expiring_soon = true
• Raw: current_storage_used_gb = 87.4
• Not raw: over_80_percent_storage_used = true

If you give your CRM the raw number or date, you can do whatever you want with it later. If you give it a sliver of logic someone hard-coded upstream, you are stuck with that decision until you convince someone in your product or engineering team to change it.

In marketing, nothing is constant.

Lifecycle is all about timing, thresholds, and conditions. And those things change a lot.

Your timing will change.

Today, you might want to warn people 14 days before their reward points expire. Six months from now, you might learn that 7 days before performs better. Later, you might decide on a 3-touch sequence at 21, 7, and 1 day.

If you asked your product team to send an event when a member is 14 days from their expiration date or an attribute such as:

Rewards_expiring_14_days = true

you are now blocked every time you want to adjust timing. You need new events, new logic, new QA, and a slot in someone’s sprint. But, if you’re sent :

Rewards_end_date = MM-DD-YYYYTHH:MM:SSZ

Set up your own rules in Braze, Iterable, SFMC, whatever you use:

• Send email 1 when today = subscription_end_date – 14 days
• Send email 2 when today = subscription_end_date – 7 days
• Send SMS when today = subscription_end_date – 1 day
  

You don’t need to submit a Jira ticket. You have all the information you already need.

Your thresholds will change.

Same story with usage-based products. If your membership levels are based on storage usage, and you send:

• current_storage_used_gb
• storage_limit_gb
  

You can run a dozen different experiments over time:

• “Nudge at 70 percent, push upgrade at 90 percent.”
• “Test a usage digest email every Monday.”
• “Offer a temporary boost when someone hits 100 percent.”
  

But, if you send a binary flag like:

approaching_storage_limit = true

You now have no idea what “approaching” means without digging into legacy documentation. And if you want to change that threshold, you are back in someone else’s backlog.

Your business model will change.

This is the big one people forget. And, when it does, your engineering team will be heads down, creating new, revenue-driving code to match the new model. Your emails are not their top priority. 

If your events and attributes are tightly coupled to the current marketing approach, your database becomes a graveyard of half-understood events when the business changes.

It is much easier to explain “this is the date something happened” than “this was a special flag from three pricing models ago and no one is sure what it means now.” Future you will be grateful that you decided to keep things generic and flexible.

What This Looks Like

Here are a few common patterns and how I would handle them.

Usage-based nudges

Ask for:

• current_storage_used_gb
• storage_limit_gb
• last_updated_at (optional)
  

In your CRM:

• Create segments by percent of storage used.
• Trigger alerts when someone crosses a threshold.
• Test different upgrade prompts without touching the data feed.
  

Rewards and points

Ask for:

• reward_balance
• reward_expiration_date (per bucket if you have rolling expiry)
  

In your CRM:

• “Your points are expiring soon” journeys based on date math
• “You have enough for X reward” messages based on balance logic

“But engineering says this is easier their way.”

You will probably hear one of these:

• “It is easier if we just send you a 14-day reminder event.”
• “We already calculate ‘approaching limit’ for the UI.”
• “We do not want business logic duplicated in multiple places.”

Totally valid concerns, but here is the counterpoint:

1. CRM rules change faster than product logic. Marketing needs to run tests, adjust timing, and pivot messaging much more frequently than teams want to ship code.
   
2. Raw data is reusable across teams. Product, analytics, finance, and marketing can all use “end date” or “usage” data differently. A one-off flag is usually useful to one team and confusing to everyone else.
   
3. You can still mirror their logic if needed. If the application already calculates “approaching limit,” great. Keep that for the UI. Still pass the underlying usage number so CRM and analytics stay flexible.

Try This Week

If you want a concrete action item, here is your mini-audit:

1. Pick one key lifecycle journey. Renewal, trial conversion, usage upgrade, or expiring rewards.
   
2. List every event and attribute you use for it today. Look for anything that sounds like a pre-baked decision:
   • *_in_14_days
   • *_expiring_soon
   • *_approaching_limit
   • Booleans that describe timing instead of facts
     
3. Identify the raw data behind those flags. What actual date, count, or amount is that flag based on?
   
4. Plan a data request to shift to raw fields. You might not get it all done this week, but at least you will know what to ask for the next time you touch the integration.
   
5. Update your data dictionary. Document the raw fields, how they are used, and deprecate the legacy “magic” flags as you phase them out.
   

Remember: Dates and numbers in; opinions and timing rules out.

Your future campaigns, future teammates, and future self will have a lot more freedom to experiment, iterate, and clean things up without opening a single engineering ticket.