> ## Content Index > Fetch the complete content index at: https://www.martechtherapy.com/llms.txt > Use this file to discover other available public pages before exploring further. # Same word, different meaning - URL: https://www.martechtherapy.com/helping-marketing-and-data-engineering-same-word-different-meaning/ - Published: 2026-09-14T05:58:16.000Z - Updated: 2026-09-14T10:15:53.000Z - Description: The words marketing and data engineering both use and define differently, and what each side hears instead. One page, free, take it into the meeting. - Author: Matthew Niederberger - Tags: Customer Data Platform, Sponsored, Databricks SPONSORED ![CTA Image](https://storage.ghost.io/c/57/c5/57c5ffb5-ecd9-4bf6-b870-68986d981176/content/images/2026/08/Databricks_idF4fnHpaJ_14.svg) ****Sponsored by Databricks.** [Databricks](https://www.databricks.com/?ref=martechtherapy.com) commissioned and funded this guide and reviewed it before publication for factual accuracy. They did not get to change the conclusions. [Full disclosure at the foot of this post](#about-the-series). A client of mine moved from head of IT to head of Martech at a national UK company. Technical background, ran engineering teams for years, nobody's idea of a novice. The first honest thing he said to me was that he *didn't know how to talk to data engineering*. That surprised me, and then it stopped surprising me. He had the vocabulary, and the vocabulary was the problem, because every word he needed already meant something slightly different on the other side of the table, and nobody had told either party. Here is a request I have seen a version of many times, usually in Slack: > Can you sync the lapsed-customer audience to Braze in real time? Just needs the churn model score on each profile. Nothing about that is unreasonable. It also contains six words that mean something different to whoever receives it than they did to whoever wrote it. Sync, audience, real time, model, profile, customer. This page is those words. I've now watched this happen enough times to stop treating it as a people problem. Most Martech projects don't stall on disagreement, because disagreement is visible and someone escalates it. They stall on the false kind of agreement, where two people leave a meeting *certain they decided the same thing*. Six weeks later the segment refreshes daily instead of hourly, the profile is missing the field the campaign was built on, and nobody can point at where it went wrong. So where did it go wrong? In the first half hour, when somebody said "real time" and we all nodded along. Before I continue, a quick word on where this came from. I wrote about [CustomerLake when Databricks launched it in June](https://www.martechtherapy.com/databricks-customerlake-the-warehouse-cdp/), and that turned into a run of conversations with their team. We kept arriving at the same observation from different directions: > The marketers who end up living with these architectures often cannot describe what they need in terms the people building them can act on That gap is not specific to Databricks, and it is definitely not new. So they offered to fund a set of guides about it, and I said yes. One caveat before the list. These are not standard definitions, because *there are no standard definitions*. They are the interpretations I run into most often. Treat them as prompts for a conversation rather than as a glossary, and use them to establish what each word means in your company. ## Six words, two meanings each There are twenty-four of these on the sheet. Six need more than a line, because they are the ones I have watched cost people whole quarters. The rest are on the printable version. ![](https://storage.ghost.io/c/57/c5/57c5ffb5-ecd9-4bf6-b870-68986d981176/content/images/2026/09/talking-to-data-engineering-01-same-word-different-meaning-promo-1.png) Take it into the meeting Two sides of A4\. Twenty-four terms, what each side means, and the misreadings that run both ways. [Download the PDF ](https://www.martechtherapy.com/content/files/2026/09/talking-to-data-engineering-01-same-word-different-meaning.pdf) ## Don't miss it when guide #2 drops. Practical Martech insights delivered straight to your inbox. Sign up for the newsletter below 👇🏻 Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. ### Real time You usually mean *soon enough* that it does not feel broken. They hear *sub-second streaming*, which means infrastructure running continuously and a bill that arrives whether or not a campaign is using it. Nobody has said a number yet. There are several useful speeds between a nightly batch and true streaming. When people are pushed to say what they actually need, fifteen minutes is often enough, and sometimes daily is. So *name the moment rather than the speed*. What has to be acted on before it goes stale, and what does it cost you when it is an hour late? A cart abandonment email that arrives the next morning is worthless. A loyalty tier that updates overnight is fine. Those two need different architectures, and the gap between them is most of the budget. I wrote about where vendors draw that line in [real-time from a warehouse](https://www.martechtherapy.com/right-time-marketing-and-the-speed-of-context-decay/) and guide 3 will be entirely about this topic. ### Model You mean a prediction. Propensity to churn, likelihood to convert, next best offer or action. They mean the data model, which is the tables and how they relate to each other. Most of the words here surface eventually, because somebody asks a follow-up question and the confusion turns up while it is still affordable. This one does not. Nobody asks a follow-up, because nobody thinks one is needed. So you asked for a churn score, and three weeks later they walk you through an entity relationship diagram. Say score or prediction when you mean the first. Say schema when you mean the second. Try not to say model at all in a room where both meanings are live and egos present. ### Segment and audience Worth taking together, because you use them interchangeably and data engineering does not. On segment, what they need to know is whether you mean the *definition* or the *result*. A saved query and a materialized table are different objects with different costs, and which one you meant changes what gets built. And budget often plays a deciding factor. Audience is usually narrower on their side. It often means the *exported copy*, the version pushed to the destination, rather than the logic that produced it. So "the audience is wrong" tells a data engineer almost nothing. It might mean the logic is wrong, which is yours. It might mean the export is stale, which is theirs. Those go to different people and take different amounts of time. Say which one you think it is, and what made you think so. ### Customer You mean a person. They mean an entity at a particular grain, which might be a person, an account, a household or a device, and they need to know which identifiers represent it. It sounds pedantic until the first time it goes wrong. In B2B, the customer is usually the account, so treating it as a person sends five people at the same company the same renewal notice. In streaming, the customer is often a household with five profiles and one bill, so treating it as a person builds someone's recommendations out of their teenager's viewing. Ask which grain before you ask for anything else. I have saved myself whole weeks with that question, and I still forget to ask it. Guide 4 covers what happens when the grain is right, and the matching is not. I went further into that in [the identity resolution guide](https://www.martechtherapy.com/identity-resolution-a-practitioners-guide-to-who-owns-the-match/). ### Source of truth You mean the dashboard you trust. They mean the designated system, governed dataset, or semantic definition that everything else derives from, which is usually not a dashboard. There can legitimately be more than one. Identity, consent, revenue and campaign performance can each have a different source of truth, chosen on purpose, and none of them is wrong. So when your number disagrees with their number, ask which system each of you is reading from, and whether that system is the designated one for the thing you are arguing about. Usually you are both reading correctly, from different places. ### Governance You mean the reason things take longer. They mean the reason the company has not had to disclose a breach. Both are true. There is no misunderstanding here to clear up, only a difference in what the two of you are measured on. Concede it early and out loud. Say you know the constraint is not bureaucracy, and that you would rather work inside it than around it. It is true, and it changes how the rest of the meeting goes. Guide 5 will be about who is actually allowed to say yes. ## Before the next meeting Take the brief for whatever you're about to build. Find the three words in it that appear on this page. Ask each side to define them out loud, in a sentence, before anything else gets discussed. That's it. Is it too obvious to be worth writing down? Probably, and I've watched enough projects lose a quarter to that exact obviousness to keep doing it anyway. It's the cheapest de-risking available to either of you, and the alternative is finding out in week six. The one-page version Twenty-four terms, what each side means, and the misreadings that run both ways. [Download the PDF ](https://www.martechtherapy.com/content/files/2026/09/talking-to-data-engineering-01-same-word-different-meaning.pdf) **Next in this series:** how to write a data request someone can act on. All six live on the [Helping Marketing Talk to Data Engineering](https://www.martechtherapy.com/talking-to-data-engineering/) page as they publish. ## About the series #### Series Sponsorship Disclosure Databricks came to me in the summer of 2026, after the agentic CDP series, and asked whether I would write a set of practical guides for marketers. There are six of them, and you are on the first one. Here is the arrangement in full. Databricks reviews each guide before publication and may suggest factual corrections. Anything they flag as factually wrong, I fix. Anything they would prefer I said differently, I do not. The conclusions, the structure and the tone are mine, and so is the decision about what goes in and what stays out. The guides are educational resources, not product recommendations. None of the six guides names a Databricks product, and none of them concludes that you should buy one. Would I have written something like this anyway? Probably, eventually, in pieces. Their support is why it happens now, as a series, with enough time to do it properly. Nothing here is gated. No form, no email capture, and the PDF is a direct download. If you think I have something wrong, or have overlooked an important perspective, please tell me. I would rather know. Do you have any questions after reading this article? Or need support with your Martech projects? [Contact me today >> ](https://www.linkedin.com/in/matthewniederberger/?ref=martechtherapy.com)