A customer score has value when it changes a decision. A score calculated in advance, stored for days, and never used still consumes compute and creates data that your teams must retain and govern. As customer experiences move closer to real time, the design question is no longer just which inference to run. It is where to run it, when to run it, and whether a device or a customer-owned service should do the work.

Three patterns help make that choice: batch inference owned by the customer, real-time inference requested when needed, and a hybrid model that uses on-device inference where supported and customer-owned inference elsewhere. Each changes the relationship between usage, compute, and stored output.

Shifting from scheduled scores to inference at the moment of need

Batch scoring is familiar. A model processes a population on a schedule, and the resulting scores are written to a store for later use. That pattern suits use cases where the score remains useful over time and downstream systems need a persistent value.

The trade-off is that batch cost is largely committed before anyone uses the result. Some scores become stale before activation. Others are never read at all. The organization has still run the job and stored its output. For high-volume use cases, the gap between scores produced and scores acted on deserves attention alongside model accuracy.

A real-time pattern changes the trigger. Rather than calculating every score in advance, the experience requests inference when a qualifying interaction needs it. Tealium Functions can support this approach by calling a customer-owned inference service on demand. The decision moves closer to the customer moment, and the system can avoid generating outputs for interactions that never call for them.

This does not make real-time inference free. It changes the cost profile. Compute is tied to requests rather than a scheduled population-wide run, and the implementation must account for request volume, service capacity, response time, and reliability. The output can also be limited to what the activation needs, reducing the volume of stored scores when persistent storage is not required.

A third pattern adds on-device inference where the use case and device support it. In a hybrid design, the device handles inference locally for supported interactions, while a customer-owned service handles the remaining interactions. The model and placement decision determine the split. The aim is not to move every inference to a device; it is to avoid sending work to a central service when local inference is appropriate.

How the architecture works

Batch: calculate first, use later

A scheduled pipeline selects a population, runs the model, and writes scores to a customer-owned store. Activation systems read those scores when they need them. This is a good fit when downstream consumers need a durable score or when the underlying data changes slowly enough for scheduled refreshes.

The operational questions are straightforward: how often does each score get used, how quickly does it lose value, and how long must it stay available? If those answers are unclear, the organization is paying to produce and retain outputs without knowing whether they affect a decision.

On demand: request inference when a use case needs it

In an on-demand flow, an interaction reaches the orchestration layer, which invokes a Tealium Function to request a result from the customer-owned inference service. The response can then inform the next action in that experience. The exact request and response contract depends on the service and use case, so teams should define it before implementation.

Hybrid: use local inference where it fits

A hybrid design routes supported interactions to on-device inference and sends other interactions to the customer-owned inference service. The response path then returns the result to the experience that needs it. The precise routing depends on device capability, model placement, privacy requirements, and the decision's latency needs.

Where the use case supports this split, the customer-owned service handles fewer requests. That can reduce central compute and the amount of output that needs to be stored. The total number of useful inferences can remain similar; what changes is where those inferences run and how many central calls are necessary. Validate this with measured workloads rather than assuming the hybrid pattern always costs less.

Example use cases

A time-sensitive experience

A site interaction signals that a customer is considering an offer. If the decision depends on a fresh model result, an on-demand request can return context for the next experience step. The team should define the latency budget and the fallback behavior before connecting the request to a live journey.

A durable planning score

A durable planning score teams over a defined period. Batch processing and persistent storage can be appropriate here. The key is to measure whether the stored score remains current and whether consumers actually use it.

A device-supported interaction

For an experience with a supported device and model, on-device inference can handle the decision locally. A hybrid design can reserve the customer-owned service for devices or use cases that do not support local inference. Teams should verify model compatibility, result consistency, and how each path is monitored.

Why Tealium's role matters

The orchestration layer determines when an interaction needs a model result and where the next action takes place. That makes it an important part of the inference design, not a replacement for the model or the customer-owned service.

• Connect the moment to the decision: Use customer interactions and defined journey logic to identify when a result is needed.
• Call services as needed: Tealium Functions can connect an eligible interaction to a customer-owned inference endpoint, subject to the agreed request, response, and operational design.
• Keep model ownership clear: The customer's model or inference service performs the inference. Tealium carries the relevant context into the flow and supports the action that follows.
• Choose what to retain: Design the response path around the downstream need. A persistent score is useful when consumers require it; a transient result does not need to become another long-lived data asset by default.
• Compare architectures with evidence: Track call volume, compute consumption, response time, unused outputs, and storage over representative workloads. The right pattern depends on those measurements and the use case.

The bigger takeaway

Inference cost is not only a question of model size or cloud price. It is also a question of how many results you generate, how many are used, where computation happens, and how much output you retain.

Batch processing remains a sound choice when scores need to persist. On-demand inference fits decisions that depend on a live interaction. A hybrid approach places some work on the device and keeps customer-owned inference available for the rest. Start with the decision, map the moment it needs a result, and choose the architecture that serves that moment without producing data nobody uses.

The post Choosing Where Inference Runs: A Practical Cost Model for Real-Time Customer Context appeared first on Tealium.

More of that now happens in a chat window. People describe a problem, ask follow-up questions, and narrow their options, sometimes without ever seeing a results page.

With ads now appearing for eligible users on ChatGPT’s Free and Go plans, marketers have another place to reach people as they work through those decisions.

Search advertising taught marketers how valuable it can be to show up when someone is actively looking for something. Conversational discovery brings a different experience to that same moment.

Imagine someone planning a trip. They describe their budget, explain who’s traveling, and work through what kind of vacation makes sense. A relevant ad gives them another option to explore.

Then the conversation ends, and the customer journey keeps going. The booking happens on your site. Maybe they start checkout and come back two days later. Maybe the transaction is finalized in a reservation system after the browser session is long gone.

Like other walled gardens, ChatGPT Ads needs signals from your business to understand what happened after the click.

That’s where measurement comes in. You need to know whether those visits turned into bookings, purchases, or leads before you can decide how much to invest.

Two routes, one event

The ChatGPT Ads Pixel captures website actions as they happen: product views, leads, checkouts, and purchases. It gives teams a quick way to get measurement running and uses a first-party cookie to retain its ad attribution identifier.

That reduces reliance on third-party cookies, but browser measurement still has limits. Blockers and interrupted sessions can leave gaps. And a pixel on your website can’t capture a transaction that happens entirely in a backend system.

The ChatGPT Ads Conversions API, or CAPI, helps fill those gaps. It provides a direct server-side route for conversion events, so a confirmed purchase from your backend can be reported even when the browser misses it.

Together, the two can give you a more complete picture. You just need to make sure they agree on what happened.

If the same purchase goes through both routes, a shared event ID lets ChatGPT Ads recognize it as one conversion. Without that coordination, you risk counting the purchase twice and making the channel look more effective than it is.

Tealium supports both today

Tealium supports the ChatGPT Ads Pixel + CAPI, with customers already using our server-side connectors and deploying the pixel through tag management.

Through Tealium Tag Management, teams deploy the ChatGPT Ads Pixel using the data layer, event mappings, and load rules they already have. The tag respects Tealium consent state and doesn’t fire when consent is denied.

On the server side, Tealium sends events to ChatGPT Ads CAPI. Teams map conversion events, include transaction details, and control which supported identity signals they share.

If you already have a purchase event defined in Tealium, you have a starting point. You can use that work to set the browser trigger, connect the backend confirmation, and align event IDs across both routes. Consent and data-sharing rules should carry through both as well.

Adding a channel should build on the data work you’ve already done.

Build on the measurement foundation you already have

Tealium has helped advertisers connect first-party conversion data with platforms including Meta, Google, Amazon, and LinkedIn. The same practical concerns come up across those integrations: send consistent events, make delivery reliable, and keep control over what gets shared.

We’re bringing that experience to ChatGPT Ads and look forward to working with OpenAI as the channel develops.

The way people discover your brand will keep changing. Marketers need the flexibility to follow them, along with the data to understand whether that investment is working.

Getting measurement in place now gives you a way to learn from this channel and decide where it belongs in your strategy.

The post A New Front Door for Discovery is Opening. Introducing ChatGPT Pixel and CAPI appeared first on Tealium.

Should someone reach out? Does the customer need help with a product issue? Would another promotional email make the situation worse? What is the right image to show this customer?

These are the kinds of questions that make Jev, a new model from TypeSafe AI, really interesting. It takes context and returns structured, probabilistic answers that can be used for a variety of automation and experiences. For organizations moving customer data through Tealium, that creates an opportunity to explore more nuanced decisions inside the workflows they use today.

A model built for decisions

TypeSafe introduced Jev earlier this month September as its first “System One” model, designed for fast, bounded judgments. You provide the context and define the questions and possible answers. Jev returns structured values through its API, with probability signals your application can use. 

There are three question types:

• Choice: Select from a defined set of options, such as routing a customer to technical support, billing, or an account manager.
• Score: Evaluate something against a rubric, such as the urgency of a service issue.
• Noul: Evaluate whether a statement is a yes or no and return a probability between zero and one, such as whether a customer’s message expresses an intention to cancel.

Multiple questions can evaluate the same context in one API call. Choice and Score also return confidence values. The answers arrive as structured JSON, resulting in defined values to work with. 

That is an appealing format when the next step is updating an attribute, evaluating an audience, or routing a task. Your team defines what the answer means for the business and which actions it can trigger.

Tealium Functions supports Jev (available now) 

Tealium Functions gives customers a way to call external model APIs using event or visitor data. A function can assemble the relevant payload, send it to a model, and receive a result. Returned values can then flow through Tealium, where configured enrichments write them to profile attributes for audience evaluation and downstream activation.

The useful part is how much of the surrounding work may already be in place. You have events, customer profiles, audience rules, and connected destinations. You can build on those investments to test a new kind of decision.

Recognizing when a customer needs help

Consider a subscription customer whose usage has declined over the past month. Yesterday, they submitted a support message about a recurring problem. Today, they visited the cancellation page.

A cancellation-page visit alone tells you very little about the reason. The recent support issue and change in usage give that visit more meaning.

A team could bring that sequence together in a payload and ask Jev to assess the strength of the warning signs against a defined rubric. A separate Noul question could evaluate whether the support message expresses an intention to leave. Choice could help classify the issue for the right team.

Those answers could inform a retention workflow: prioritize a service follow-up, route the issue to someone equipped to resolve it, or pause an unrelated promotion where the connected systems support that action.

The score gives the team a way to evaluate the combination of behaviors and the customer’s own words, then test whether the resulting intervention helps.

Choosing a more useful next step

Now imagine a shopper comparing two expensive products. They have returned several times, reviewed delivery information, and asked whether one model works with equipment they already own.

A discount given as an incentive for purchase wouldn’t solve for a compatibility question, and would just leak margin. 

A retailer could ask Jev to choose among a small set of next steps: offer compatibility help, provide a product comparison, explain delivery options, or continue the existing experience. The payload would include the relevant browsing sequence and the customer’s question, where permitted.

The result could become an attribute that a connected experience platform uses at its next decision point. If the answer is ambiguous, the workflow could keep the existing experience or offer a simple way to ask for help.

This also gives teams something specific to measure. Did customers who received compatibility help complete their purchase more often? Did they return fewer products? The test is whether the decision improves the experience and its outcome.

Describing the customer you want to reach

Marketers often know who they want to reach before they translate that audience into attributes and rules. Jev could give them another way to evaluate the fit: describe the customer in plain language, define what a strong match looks like, and ask the model to assess the profile.

Imagine a retailer planning for the holidays. The team describes three audiences: seasonal gifters, loyal high-value customers, and casual shoppers. A customer’s purchase history shows orders concentrated around the holidays, several with gift wrap. This week, they have browsed multiple products in different categories. Together, those signals give the model more context for assessing a gifting pattern than purchase timing alone. The context from each profile informs a Score question, with criteria describing what a weak, partial, or strong match might look like. 

Those scores can become profile attributes that a marketer uses to build audiences or help determine which message a connected channel serves. The gifter could see gift guides and shipping deadlines. The high-value customer could see early access. The casual shopper could see new arrivals or deals in a category they have browsed. 

The marketing team can refine those descriptions as a campaign evolves and the workflow could rescore profiles as relevant new events arrive, using the same activation paths already in place.

Speed and cost expand what is worth testing

TypeSafe reports end-to-end response times of 70–500 milliseconds and launch pricing of $0.042 per million input tokens, with no output-token charge. Its published evaluations show substantial speed and cost advantages over the chat-based models it tested.

What might be more interesting though is that this model call is fast and inexpensive enough that teams could consider using it for smaller, more frequent decisions. More moments become worth evaluating.

An initial experiment could run alongside an existing workflow, recording Jev’s answers without changing customer treatment. Compare those answers with what your team would have chosen and what actually happened. That gives you evidence for deciding where to introduce automation.

Room for the next idea

Tealium’s role is to give customers the flexibility to connect their data to the models and services that suit their ideas. Functions extends that flexibility to API-accessible systems, including those without a prebuilt integration. 

As new approaches like Jev emerge, you can evaluate them against a real customer problem, using the data streams and activation paths you have already built.

We continue building infrastructure for your best ideas. And that gives you room to try something that was not on anyone’s roadmap when you first connected your data.

The post Tealium Functions adds in-stream intelligence with disruptive new model Jev appeared first on Tealium.

There were three ways around it, and I used all of them. We invested in data clean rooms, where we could match our file against the platform's data and get answers back, as long as we accepted the platform's limits on what we could ask. We bought into second-party data sets and marketplaces to borrow resolution we couldn't generate ourselves. And when neither was enough, we fell back on machine-learned modeling to predict the impact a garden had on the rest of our advertising, because we could not observe it at the user level. Each approach was a proxy for the one thing the garden withheld: the resolved individual. Two of the three were just more things to rent.

The gardens have never hidden the terms: your data goes in, and only aggregates come back out.

None of this is a complaint about how the platforms behave. Strip the vendor language off a data clean room and it does one thing: it lets you load your own customer file, match it against the platform's data inside the platform, and take out aggregated insight — with no individual's information ever appended back to your original set, and no user-level record allowed to leave. You bring your data in; the platform decides what, if anything, comes back out. The reach is real and the optimization is real, but what you learn about your own customer stays the platform's to know, not yours to keep.

That was a tolerable trade while the open web still gave you somewhere to build your own identity and measurement capabilities. You could resolve people outside the walls and reason about what happened inside them. Connected television is changing that quickly.

Connected TV is turning the entire television budget into walled-garden spend.

The garden problem used to be limited to search and social. Now it is spreading across television. Amazon made Prime Video ad-supported by default in January 2024, moving roughly a hundred million U.S. subscribers into an ad audience effectively overnight, and its ad-supported base is now past three hundred million globally. Netflix's ad tier grew to more than two hundred fifty million viewers by its spring 2026 upfront, with over half of new signups now choosing the ad-supported plan. Streaming crossed a record 47.5 percent of all U.S. television viewing at the end of 2025.

That budget is not moving into one garden. It is spreading across Netflix, Amazon, Disney, Roku, and a long tail of free ad-supported services, and each has its own measurement system, with results that do not reconcile cleanly with the others. The identity problem I used to have with two or three platforms now spans a dozen, each with its own clean room, its own rules, and a different version of the truth about a viewer I still cannot resolve on my own.

Measuring inside the garden keeps getting cheaper while the independent alternatives disappear.

The economics are moving in the platforms' favor at the same time. Amazon made its Marketing Cloud clean room free to every Sponsored Ads advertiser in September 2025, which looks generous and draws advertisers further in — the easier it is to measure inside the garden, the less reason anyone has to build resolution outside it. And the independent options are thinning. The neutral clean rooms and identity businesses that once sat between the brand and the platform are being absorbed, with LiveRamp taking in Habu and WPP's GroupM acquiring InfoSum. The middle ground, where a brand could reason across gardens on neutral terms, is quietly narrowing.

The one input that decides everything is the resolved identity the gardens cannot give you.

The deciding factor is identity match rate, which limits everything a clean room can tell you. The garden's answer is only as good as the share of your file it can recognize, which means the value you take out is set by the resolved identity you bring in. The platforms cannot hand you that. It is the one input the walls are built to keep you from removing, and it is the only input that turns a garden from your system of record back into what it should be — a place you distribute to, not the place that decides who your customer is.

So the position worth holding was never "get inside the gardens." The spend was always going to be there. The position is to resolve the individual on your own side of the wall, before the impression ever crosses into a platform, so that what you carry into every clean room and every ad tier is identity you already own. Do that, and the garden becomes a channel again. Skip it, and you spend a television budget renting proxies for the customer the garden never let you keep.

The post Inside the Gardens You Own Nothing appeared first on Tealium.

Australia's privacy framework is facing its most significant overhaul in more than a decade. The Attorney-General's Department has released an exposure draft of the Privacy Amendment (Personal Data Protection) Bill 2026, signalling a material shift in how customer data must be collected, used and governed. The legislation is not yet final, but organisations that wait for royal assent before acting will find themselves starting from a more difficult position.

Before taking any steps, it’s very important that you liaise with your internal privacy and legal teams to align and ensure you are compliant.The guidance below is a practical starting point, not legal advice.

What is the "fair and reasonable" test, and why does it matter?

The most important change in the Privacy Amendment (Personal Data Protection) Bill 2026 is the introduction of a new standard: collection, use and disclosure of personal data must be fair, reasonable and proportionate.

Under Australia's current Privacy Act 1988, consent provides a primary line of defence. The proposed framework changes that. An organisation can have a consent banner in place and still fall short of the new standard if the data use is excessive, unexpected, or primarily self-serving. Consent becomes one control in a broader governance framework, not a standalone answer.

For organisations that have built their data practices around consent as the primary mechanism, this is a structural shift, not a cosmetic update.

What does the Privacy Amendment (Personal Data Protection) Bill 2026 change?

Several provisions matter directly to customer-data teams:

Broader definition of personal information. Data that can identify someone when combined with other reasonably available information would fall within scope, not just data that identifies them directly. Device identifiers, behavioural patterns, browsing data and AI-generated inferences may all require the same governance discipline as directly identifying data.

Stricter consent requirements. Consent would need to be voluntary, informed, current, specific and unambiguous. Pre-ticked boxes and bundled permissions would not meet this standard.

Targeted advertising clearly in scope. The draft brings advertising directed to an individual, audience, segment or cohort within the direct-marketing framework, including online behavioural targeting. This reaches directly into how most digital campaigns are built and activated.

Breach notification tightened. Eligible data breaches would require notification to the Privacy Commissioner within a proposed 72-hour window.

Deletion and de-identification obligations. Organisations would need to consider destroying or de-identifying personal information they no longer need. Data without a clear current purpose becomes a liability.

Right to erasure for large digital platforms. A specific erasure regime would apply to large platforms, with clear obligations around how and when data must be removed.

One point worth emphasising: the proposed requirements would apply to existing customer lists, historical data relationships and partner feeds, not only to newly collected data. There is no assumption that current arrangements are grandfathered.

Actions you can take now

The practical work falls into three areas. These are questions worth working through with your data, marketing, legal and technology teams before the legislation is finalised.

1. Audit your data collection and tag environment

• Do you have an up-to-date inventory of every tag, pixel and connector active across all your digital properties?
• Which companies are receiving data from those tags, and is any of that data being transmitted overseas?
• What data is being collected directly, and what is being inferred from behavioural or event signals?
• Can you minimise the data collected to what is genuinely required for each use case?
  

2. Review your consent management framework

• Are you capturing consent across every channel where personal data is collected?
• Does consent meet the proposed standard: voluntary, informed, current, specific and unambiguous?
• Can customers easily opt out, and can they change their preferences at any time?
• Are your tags and connectors automatically enabled or suppressed based on consent status?
• When a preference changes, does that signal propagate consistently across every downstream platform and activation path?
  

3. Map your vendor and partner data flows

• Do you have a clear record of which vendors and platforms receive customer data, for what purpose, and under what terms?
• Which relationships are processor-only, and which involve vendors who may retain, enrich or reuse data beyond your written instructions?
• Can you retrieve, delete or de-identify the relevant data across every system in your environment if a customer requests it?
• Are your existing partner permissions and customer lists defensible under the proposed fair-and-reasonable standard?
  

Tealium can help you prepare for the privacy reforms in several way

Tealium helps organisations build the governed data foundation these questions require, alongside the consent-management, warehouse and activation tools already in place.

Data collection with governance built in. Tealium captures first-party event data across web, mobile, server-side and API sources through a single governed layer. Every collection point can be configured to respect consent status from the point of capture, so the data flowing downstream reflects the customer's actual preferences.

Consent propagation across activation. When a customer changes their preferences, that signal needs to reach every downstream platform, not just the consent banner that captured it. Tealium connects consent status to activation decisions, so suppression is consistent rather than manual and ad hoc.

Full visibility of data flows. Tealium maps data from source through to every downstream destination, with the consent signal and purpose attached. That gives marketing, data and security teams a shared view of what data exists, where it has gone, and what permissions apply.

Vendor relationship classification. With over 1,300 connectors, Tealium helps organisations classify outbound connections by data-use type, supporting the review of which vendor relationships are processor-only and which may require closer scrutiny under the proposed framework.

Across all of this, the aim is the same: give marketing, data and security teams a single, governed view of what data exists, what permissions apply, and where it has gone, so that compliance can be controlled rather than just assumed.

Don’t Wait - Take Control Today

To get practical, independent guidance on where to start, join Chris Brinkworth, Director at Civic Data, and Tim Till, RVP Field Engineering & Ecosystem Development APJ at Tealium, for an upcoming live fireside chat covering what the proposed reforms mean in practice and the specific steps your team can take to prepare.

8 October, 11:00am AEST | Register here

This article is based on publicly available information about the proposed Privacy Amendment (Personal Data Protection) Bill 2026 exposure draft and should not be treated as legal advice. The proposals remain subject to consultation and may change before legislation is introduced or enacted.

The post Australia’s 2026 Privacy Reform: What Customer-Data Teams Need to Do Now appeared first on Tealium.

A national pharmacy retailer came to us to drive vaccinations, and the campaign that moved the numbers was not the one with the most inventive media plan. It was the one with the right append. We layered real-time Google demand signals — localized search behavior read at the DMA level — over AmeriLINK, the holding company's own consumer data asset, resolved to people who lived inside a given DMA and within reach of a store. Each person had a profile of more than eight thousand observed, self-reported, and modeled variables. Engagement came in 47 percent higher than the control. Appointment rates ran 43 percent higher. Cost per acquisition fell by a fifth. The model that scored the audience and the platform that spent against it were competent and interchangeable. The data was the difference, and everyone on that account knew it.

For much of the last two decades, the append was the advantage, and the business was organized around it. You licensed a set — from Merkle, Epsilon, Acxiom, Experian, or in our case an asset that competed directly against all of them — appended it to a customer file or a media plan, and that step separated a campaign that found real people from one that spent into the dark. The holding companies built serious businesses on this. I watched one from the inside, alongside the people who ran it. A well-constructed third-party set carried deterministic offline attributes, financial and demographic depth, and household resolution that no single brand could assemble on its own.

That world consolidated in plain sight. Publicis bought Epsilon. Dentsu absorbed Merkle. IPG took Acxiom's marketing arm, and last November IPG itself disappeared into Omnicom to form the largest advertising company in the world. The data businesses that had been the play were folded into the holding companies and priced as strategic assets.

Somewhere in the following years the industry adopted the opposite belief. The algorithm became the headline — the bidding logic, the lookalike engine, the optimization layer — and data was recast as fuel for a smarter machine. That framing held because the machines were hard to build, and the teams that built better ones won more often. Advantage looked like engineering because engineering was scarce.

It is not scarce now. Meta's Advantage+ and Google's Performance Max took the machinery a buyer used to assemble by hand and turned it into a setting. The targeting model, the bidding logic, the creative optimization — you no longer build them, you switch them on, and so does your competitor. The AI layer now moving into media buying finishes the job. When the model is something you rent by the seat, it stops deciding who wins, and the question becomes: whose data is going in?

But the older answer has a problem the industry has been slow to acknowledge. The sets that were the play were rented too — keyed to third-party cookies and mobile identifiers, licensed rather than owned, priced on a scarcity the open web stopped protecting. Apple's App Tracking Transparency took the mobile identifier in 2021. Safari and Firefox had already switched off third-party cookies by default, which accounts for roughly a third of the web where that tracking has not worked for years.

Then the event the whole industry had braced for never happened. After five years of delays, Google confirmed in April 2025 that it would not deprecate third-party cookies in Chrome after all, and in October 2025 it shut down the Privacy Sandbox APIs it had spent six years and an enormous amount of industry investment building as the replacement. The cookieless future that every vendor roadmap had been organized around was called off, and its designated successor was retired in the same year. What that exercise revealed was not that data had lost its value. It was that rented data had lost its value, and the industry had spent six years trying to re-rent it under a new name.

So the issue is not that we are living through signal loss. We are living through the end of borrowed advantage. Advertising built itself on things it could rent — first the data, then the model — and what you rent cannot be a durable advantage when your competitor can rent it too. What survives the correction is narrower and harder to acquire: signal a brand collects itself, resolves to its own customers, and holds on its own side of every wall, available when a decision is made. That is not a workaround for the cookie. It is the asset the cookie was always a cheap substitute for.

The Walgreens result offered an early glimpse of that advantage. The real-time signal and the deep customer profile did the work, and the machine that spent against them was incidental. What follows in this series is the argument for rebuilding on that footing, starting inside the walled gardens, where a brand can put its data in and never get it back.

The post The End of Borrowed Advantage. Why the data you own makes the difference. appeared first on Tealium.

To the customer, this is part of the relationship with the bank.

Inside the bank, it can look like four completely different interactions.

Every day, customer signals pour in from digital banking platforms, websites, mobile apps, contact centers, branch systems, CRM platforms, marketing tools, data warehouses, and other internal systems. Banks are expected to turn all of that activity into seamless, personalized experiences while also meeting some of the strictest privacy, consent, and regulatory requirements of any industry.

On a strategy slide, that can sound like a straightforward data problem.

In practice, it is one of the hardest operating challenges in modern banking, and one I have seen institutions struggle with throughout my career.

The reason is fairly simple: most banking technology stacks were never designed to create one shared, real-time understanding of the customer.

They were built over time. Channel by channel. Vendor by vendor. Team by team.

The website may capture customer behavior differently from the mobile app. Server-side systems behave differently from both. Branch and offline data may arrive hours later through batch processes. Even when all of that information eventually makes its way into a warehouse, the data does not necessarily use the same language or arrive at the same speed.

And that fragmentation compounds.

Different vendors use different naming conventions, schemas, and event structures. One system may define an application start one way, while another calls it something different or splits the same journey across several fields. Teams then spend valuable time reconciling schemas and normalizing terminology after the fact.

The data itself may also live in different places with very different update cycles. Behavioral signals might be available immediately. Customer profile information may sit in the CRM. Transaction history may live in a warehouse or lake. Branch and contact-center activity may not arrive until an overnight batch runs.

Some signals are immediate. Some are delayed. Others are effectively stranded.

Then a new source gets added.

In a recent conversation with a major banking client, the challenge was described plainly: bringing in another data source meant rebuilding ingestion across multiple teams, without a common standard, while inefficient reporting slowed the decisions that depended on that data often resulting in actions that are no longer relevant because the customer has moved on..

The Customer Feels the Fragmentation

Eventually, most of this data may make its way somewhere useful.

But “eventually” is not how customers experience a bank.

Marketing may be working from one version of the customer while service sees another. Analytics teams may work from yet another. AI models can be trained on information that frontline systems cannot act on in the moment.

That creates a gap between what the bank technically knows and what it can actually do.

A customer can browse a product on mobile, encounter a problem, call the contact center, and then visit a branch while every employee they interact with sees only part of the story.

The opportunity to respond in the moment disappears.

An agent asks the customer to explain something the bank already knows. A relevant offer arrives after the customer has moved on. Analytics can tell the business what happened yesterday while the channel serving the customer right now still lacks the context to respond.

In financial services, there is another layer of complexity. Privacy preferences, consent, and governance also have to travel with the customer. When data is fragmented, those controls can become fragmented as well.

This is why the problem cannot be solved simply by adding more storage, another customer-facing system, or another analytics tool.

Banks need a common operating layer for customer data.

Creating a Common Language for Customer Data

That operating layer has to do several things well.

It needs to collect signals across the major customer touchpoints and standardize them into a common framework. It needs to resolve identity across devices, sessions, and channels. It needs to enrich events with context and apply business rules as those events happen.

And it needs to do all of this while consistently enforcing consent and governance.

This is the role Tealium is designed to play.

Tealium collects, orchestrates, and activates customer data across real-time, cloud-first, and hybrid architectures, with identity, consent, and AI governance built into the platform.

Instead of allowing every new channel or system to create another version of the customer, banks can create a governed data layer that captures signals across channels and enterprise sources, resolves identity, adds context, and routes that information to the model, application, warehouse, agent, or experience that needs it.

Most importantly, this does not require banks to rip out the systems they have spent years building.

The goal is to make the existing environment work together more effectively.

That matters because banking technology stacks are not getting simpler.

Institutions will continue adding partners, compliance controls, AI models, digital experiences, and cloud platforms. They will continue modernizing core systems while balancing digital scale with the need for human service in branches and contact centers.

Without a common data language and orchestration layer, every new investment risks creating another silo.

With one, those investments can become more useful together.

What That Looks Like in Practice

Legal & General (L&G), a UK financial services provider, faced a familiar contact-center challenge.

Customers were abandoning complex insurance applications. When those customers later called for help, agents could not easily see what had happened during the digital journey.

A customer might research coverage, move several steps through an application, get stuck, and then call.

The agent would begin by asking the customer to reconstruct everything that had just happened.

The company already had much of that information. The person answering the phone simply could not see it.

L&G connected Tealium's real-time data orchestration with Snowflake's AI Data Cloud. As customers moved through web and application experiences, those signals could be unified into a profile and used to identify where friction occurred.

When the customer called, the agent could see the relevant digital behavior and better understand the likely reason for the call before the conversation even began.

The interaction could move from:

“Tell me what happened.” to “I can see where the application became difficult. Let’s work through that step.”

That is a very different customer experience.

It also changes the economics of the contact center. Agents spend less time reconstructing journeys, searching across systems, or repeating discovery questions. They are better equipped to address the likely issue during the first interaction.  First call resolution goes up and average handle time goes down.

Tealium’s contact-center materials cite a 54% increase in successful first-call resolution for L&G, while the published case study reports a 54% increase in call-to-lead conversion when customers were routed to agents who already understood their specific pain points.

This is what real-time customer context looks like in practice.

From More Data to Better Decisions

The same principle can extend beyond servicing.

One financial services organization was trying to recover customers who had started pre-approved loan applications but abandoned them before completing the process.

The problem was not a lack of data.

Web behavior existed. Mobile-app activity existed. CRM records existed. Internal credit scores existed.

But they existed in separate systems.

As a result, contact-center outreach was manual and difficult to prioritize. By the time an agent reached a prospect, the customer's intent may already have cooled.

The organization implemented Tealium AIStream to bring those signals into persistent, person-level profiles. It created dynamic audiences based on application status, loan eligibility, propensity, and recency, then prioritized contact-center outreach based on the customers most likely to convert.

Real-time call lists were sent directly to the contact-center stack, with email and push notifications providing additional touchpoints when calls did not connect.

The organization reported a 2x increase in contactability, an 11% lift in conversion for the targeted recovery journey, and 12% growth in annual digital sales attributed to recovered loan applications.

Just as importantly, the organization could update its rules and audiences in less than a day rather than waiting through a lengthy engineering or data cycle.

That changes more than campaign performance.

It changes how quickly the business can learn.

The Goal Is Not More Data

Banks already have enormous amounts of customer data.

The challenge is making that data useful at the moment it matters.

That requires a trusted, shared customer context that can move across web, mobile, branch, contact center, analytics, and AI without losing its meaning, timing, consent, or governance along the way.

The institutions that solve that problem will not simply have a cleaner data architecture.

They will be able to respond faster, reduce operational friction, give employees better context, and create customer experiences in their channel of choice that feel like one relationship with one bank.

Which, from the customer's perspective, is exactly what it was supposed to be all along.

The post Why Banks Struggle to Turn Disparate Data Into Consistent Customer Experiences appeared first on Tealium.

When was the last time you honestly evaluated your organization's customer data readiness?

If you're like most leaders, you know your data is a strategic asset, but turning that data into real-time action remains a massive hurdle. Our previous assessment surveyed over 650 marketing and IT professionals to see where businesses truly stand. The results painted a stark reality:

• Only 18% of organizations have achieved a true single customer view.
• 85% are struggling to turn insights and predictions into strategic action.
• Governance and consent outpaced every other dimension (scoring 2.8/4 on average), proving that while privacy guardrails are strong, cross-functional usability still heavily lags behind.

Most businesses find themselves stuck in the middle tier of maturity. They collect signals confidently but lack the unified, activation-ready foundation required for personalization and real-time execution. Explore a snapshot of previous survey results.

The Next Evolution: AI-Readiness and the Agentic Enterprise

As we move towards 2027, the landscape has shifted. Collecting data is no longer the differentiator; the new mandate is powering AI and intelligent agents with complete, current, and consented customer context.

To help you navigate this shift, we've evolved our data maturity framework into a personalized assessment tool designed to help you chart a clear, progressive path from data silos to an intelligent, agentic enterprise.

Our updated framework evaluates five key pillars (Data Strategy, Data Completeness, Data Accessibility, Data Governance & Consent, Data Integrity) and categorizes your organization into one of four distinct stages of maturity:

1. Data Apprentice (modern data foundation): The core challenge here is fragmented, inconsistently governed signals. The focus is on establishing a dependable foundation and clear taxonomy.
2. Data Disciple (data-tech resilience): Data is collected, but activation is slowed by disconnected channels and batch workflows. The focus shifts to making trusted data usable across the organization.
3. Data Leader (intelligent journey orchestration): You are orchestrating experiences but need identity-resolved profiles to coordinate action in real time across all channels.
4. Data Visionary (agentic enterprise): AI ambition meets governed, real-time context to enable safe, scalable AI execution.

What's Your Next Best Step?

A maturity score is only useful if it changes what you do next. The gap between collecting customer signals and acting on them is not closed by adding another tool or launching another AI pilot. It is closed by identifying the capability that is holding your next customer use case back—and building that capability in a measurable sequence.

That is what the updated assessment is designed to do. After you complete it, you will see:

• where your organization is strong and where the customer view breaks down across five dimensions: Data Strategy, Data Completeness, Data Accessibility, Data Governance & Consent, and Data Integrity;
• which maturity stage best reflects your current operating model;
• what separates your organization from the next stage; and
• the practical plays and use cases that can help you close that gap.

The progression is deliberately focused:

• If you are a Data Apprentice, start by establishing a governed data foundation: clear taxonomy, consented collection, and reliable signals.
• If you are a Data Disciple, make that data usable across the business by connecting channels, reducing batch dependency, and improving the flow of trusted data.
• If you are a Data Leader, turn unified profiles into coordinated action through identity resolution, real-time orchestration, and a focused cross-channel use case.
• If you are a Data Visionary, strengthen the governed, real-time context that AI systems and agents need to reason, decide, and act responsibly.

The goal is not to fix everything at once or pursue AI readiness as an abstract end state. It is to choose the next capability that will create the most business value, prove it in a priority use case, and use that learning to guide the next step.

Data is only as valuable as your ability to act on it. Assess your data maturity today to identify your next best step toward a complete, governed, AI-ready customer view.

The post Beyond Data Silos: Assessing Enterprise Maturity Across Technology, Data, and Marketing appeared first on Tealium.

That makes sense. Natural language is becoming a new interface for software, and people increasingly expect to be able to describe what they want instead of clicking through a dozen screens to make it happen.

But there is a bigger question the industry needs to answer:

Does every piece of software need to become the place where all of that work happens?

I don't think so.

In fact, I think the more important shift is happening in the opposite direction.

The future of enterprise AI will be defined by choice. Sometimes you will want to use the agent built directly into a product. Other times, you will want the AI assistant or agentic environment you already use to operate that product for you.

That distinction is at the heart of the latest expansion of Tealium's agentic capabilities.

Your agent should be able to work with your stack

Tealium has supported MCP-based access to trusted customer context for more than a year. That gives AI systems a way to use governed customer data as part of agentic experiences.

With Configuration MCP, that relationship goes further.

AI agents can now move from using Tealium data to working in Tealium itself. Teams can use MCP-compatible AI tools to create and modify Tealium configurations, including audiences, attributes, enrichments, and activation workflows. 

Imagine a marketer working through a campaign idea with the AI assistant they already use. They explore the audience. Refine the strategy. Work through messaging. Decide which customers they want to reach.

At that point, they shouldn’t need to stop, open another AI interface, restate the entire problem, and rebuild the context just because it is time to create the audience in their CDP.

They should be able to say: build that audience in Tealium.

Configuration MCP makes that possible.

The resulting configuration is not trapped inside the agent conversation. Proposed changes are validated and reviewed before publication, and approved configurations remain visible and editable within Tealium for the rest of the team. 

AI can accelerate the work without creating an isolated operating model that only the person using the agent comprehends.

The goal should not be to own the entire campaign process

There is a temptation in martech today to treat AI as another reason to expand the boundaries of the platform.

If marketers are using AI to brainstorm campaigns, maybe the CDP should own campaign briefs.

Then campaign planning.

Then creative development.

Then approvals.

Then project management.

Where does it stop?

There will be customers who want a version of that experience, and native agentic interfaces have an important role to play. That is why we’ve built Tealium Studio. It gives teams a natural-language way to work directly within Tealium when that is the experience they prefer. 

But that should be a choice, not a requirement.

Most enterprise marketing organizations already operate across a collection of systems. Strategy may happen in one place. Collaboration somewhere else. Creative development in another. Customer data lives across the warehouse and CDP. Activation happens through advertising, messaging, sales, and experience platforms.

And those workflows are going to keep changing.

The agent or interface a company prefers today may not be the one it prefers two years from now.

Trying to own the entire campaign planning experience assumes the vendor knows where the customer's workflow should begin and end.

A more flexible strategy is to make the platform operable wherever the work is already happening.

Agentic flexibility is an architecture decision

This is why I think MCP is more important than simply adding another chatbot to martech.

A proprietary assistant says:

Come here to use AI with our product.

An open agentic architecture says:

Use our AI experience if you want. Or bring the agent you already use.

Some teams will prefer a native agent because it is tightly integrated, highly contextual, and purpose-built for the platform.

Others will develop sophisticated workflows using broader AI environments that span multiple systems.

Developers may want APIs and configuration-as-code.

Marketing teams may want a conversational interface.

AI agents may need to operate across all of them.

The important thing is that they are working against the same governed platform underneath.

That is the strategy behind Tealium's broader agentic expansion: Configuration MCP for external AI agents, Tealium Studio for a native agentic experience, Platform APIs and a Developer Portal for programmatic workflows, and AI Recommended Audiences to help teams surface opportunities from the customer data already available to them. 

Integration will matter more than ownership

The next generation of enterprise software will not win because it owns the biggest AI interface. It will win because it fits into the way people and agents already work.

That means giving customers options: use the native agent, use APIs, use automation, or use the AI assistant your company has standardized on.

The software underneath should still be useful no matter which interface sits on top of it.

That matters even more in martech, where the workflow has never lived neatly inside one application. Campaigns cross teams, systems, data sources, agencies, channels, and technologies.

The preferred platforms will not be the ones that demand control over that entire process.

They will be the ones that can participate wherever they are needed.

That is what agentic flexibility really means: not another place marketers have to work, but a platform that can work wherever they do.

The post The Future of Agentic Martech Is Choice, Not Another Walled Garden appeared first on Tealium.

The post How We Used Our Own Stack to Personalize Tealium.com appeared first on Tealium.