Four stacks, from collection to activation

Web: The website collects permitted events and identities through Web SDK. Consent constrains collection and subsequent use. Mobile app: The app sends events through Mobile SDK and the Edge Network extension; login provides a known identity where appropriate. CRM and support: Systems of record provide attributes and preferences with stable identifiers. Source precedence must be defined. Orders and stores: Purchases and returns arrive from the backend or file ingestion; they do not depend on browser confirmation. Edge Network: The datastream routes to enabled services. The in-session personalisation path is configured here, separately from historical analysis. Source ingestion: Connectors and APIs ingest data within their schedules and limits. Data Prep maps fields to the XDM schema. Real-Time Profile: Enabled datasets contribute fragments. Identity and merge policies determine the profile available for activation. Data lake: Datasets retain ingested data according to their retention settings. Not every Profile write is assumed to create a copy here. Edge personalisation: Edge-compatible segmentation and destinations can respond during a visit when their requirements are met. RT-CDP audiences: Audience evaluation has its own cadence. Configured policies and destination restrictions apply before export. Journey Optimizer: A journey needs a configured entry, an eligible profile and channel controls. Audience membership does not guarantee immediate delivery. CJA: CJA combines datasets through a connection and a data view. It does not simply read the unified RT-CDP profile. Web and app: The experience receives decisions through the configured integration. Missing decisions and fallback content need handling. Ad platforms: The destination receives permitted identities and audiences. Acceptance and matching belong to the receiving system. Email, push and SMS: Execution depends on the channel, credentials and recipient eligibility. Sending is not the same as delivery. Analysis and feedback: Analysis relates interactions to outcomes. Ingesting outcomes supports review without making measurement automatic activation. During the visit: Web → Edge Network → Edge personalisation → Web and app. CRM to advertising: CRM and support → Source ingestion → Real-Time Profile → RT-CDP audiences → Ad platforms. App to message: Mobile app → Edge Network → Real-Time Profile → Journey Optimizer → Email, push and SMS. Purchase to analysis: Orders and stores → Source ingestion → Data lake → CJA → Analysis and feedback.

Web: The web data layer defines events and identifiers; iQ and Collect transport them according to configuration and consent. Mobile app: The SDK collects app interactions using a taxonomy consistent with the website. Orders and backend: The backend sends business events. Event identifiers support deduplication where it is required. CRM and stores: Offline data needs an identifier contract and a configured import; similarity alone does not join records. Collect: Collect receives website, app and server events. Sources are identified and validated before activation. File Import: File import turns rows into events with fields mapped to the agreed model. EventStream: EventStream validates and enriches events, routing them through configured feeds and connectors. AudienceStream: AudienceStream maintains visitor attributes and audiences. Stitching depends on configured visitor identification attributes. Event connectors: A connector action sends an event supported by the destination. Retries and deduplication are reviewed for that action. Profile connectors: Audience changes trigger configured actions. Leaving an audience also needs a removal operation. Event export: An export to BigQuery retains events for analysis; schema and retention are designed at the destination. Ad conversions: Advertising APIs receive permitted conversions. Consent, matching and deduplication remain necessary. Engagement and CRM: The receiving system uses attributes or memberships for its own campaigns. Tealium does not replace the messaging engine. BigQuery and BI: The warehouse brings together events and campaign outcomes for analysis and reconciliation, using explicit feedback ingestion. Backend conversion: Orders and backend → Collect → EventStream → Event connectors → Ad conversions. Profile from the app: Mobile app → Collect → EventStream → AudienceStream → Profile connectors → Engagement and CRM. Offline data: CRM and stores → File Import → EventStream → AudienceStream → Profile connectors → Engagement and CRM. Event history: Web → Collect → EventStream → Event export → BigQuery and BI.

Web: The website collects permitted measurement data. Server-side tagging neither removes consent requirements nor creates known identities. Mobile app: The app sends measurement events to GA4 through Firebase Analytics; its data can be exported to BigQuery. Orders and backend: Operational events use a dedicated pipeline; not every business fact needs to become a GA4 analytics event. CRM and support: Records are extracted with stable identifiers, preferences and explicit update rules. GTM server-side: The container processes requests using clients and tags. In this example it sends measurement to GA4. GA4: The export brings GA4 events to BigQuery within its limits and schedules. It is not an export of a complete CDP profile. Pub/Sub + Dataflow: Pub/Sub receives messages and Dataflow can write them to BigQuery. The team defines schema, error handling and deduplication. Cloud Storage: Files are loaded with a schema and update controls; freshness and load failures need monitoring. BigQuery · raw: Separate source datasets support quality checks and transformation rebuilds. Customer model: Dataform runs SQL transformations and checks. The team defines identifier joins, source precedence and deletion. Ads Data Manager: A supported BigQuery model is connected to a Customer Match import, respecting eligibility, fields and consent. Cloud Run · API: A custom process publishes selected attributes to a serving layer. It must implement authentication, deletion, retries and freshness. Looker: Looker queries modelled data to analyse outcomes. A visualisation does not execute a campaign by itself. Google Ads: Google Ads receives the list and applies its usage and matching requirements. Record count is not the same as reachable users. Owned web and app: The application consumes the serving layer using an authorised identity. This personalisation is developed; it is not included in BigQuery. Outcome analysis: Sales, behaviour and outcomes are compared. Campaign data needs its own feedback ingestion. CRM to Customer Match: CRM and support → Cloud Storage → BigQuery · raw → Customer model → Ads Data Manager → Google Ads. Web measurement: Web → GTM server-side → GA4 → BigQuery · raw → Customer model → Looker → Outcome analysis. Custom activation: Orders and backend → Pub/Sub + Dataflow → BigQuery · raw → Customer model → Cloud Run · API → Owned web and app. App analysis: Mobile app → GA4 → BigQuery · raw → Customer model → Looker → Outcome analysis.

Web: The website publishes permitted events with identifiers agreed across collection, warehouse and destinations. Mobile app: The app uses the same taxonomy. Login identity is propagated only when valid and authorised. Orders and backend: Operational events support reactions to purchases and returns with less reliance on browser measurement. CRM and support: The CRM retains its operational role; records are replicated to the warehouse under an update contract. Tealium EventStream: EventStream routes events to engagement connectors and BigQuery. These are configured paths with their own controls. Fivetran: A supported connector replicates records. Frequency and deletion handling depend on the connector and its configuration. BigQuery: BigQuery brings together events and records. Campaign responses also need a feedback integration. dbt · customer model: SQL models calculate attributes and audiences. Identity resolution and opt-out propagation are explicitly designed. Braze connector: The connector sends events supported by Braze with the correct user identifier. It does not replace the historical model. Braze: Braze receives events and synchronised attributes. Canvas acts according to configuration; fast and scheduled paths can arrive in different orders. Hightouch: Hightouch synchronises models with configured destinations. Keys, deletion operations and mappings are part of the contract. Looker: The analytics layer uses governed models. Conversion definitions must agree with the business. Email, push and SMS: Braze executes configured channels with preferences and contact limits. Outcomes return through a separate ingestion. Google and Meta Ads: Lists and exclusions are synchronised where supported. Matching, permissions and timing are checked in each platform. Outcome analysis: The team compares calculated, sent and accepted populations. Each count describes a different stage. Event to message: Orders and backend → Tealium EventStream → Braze connector → Braze → Email, push and SMS. History to audience: CRM and support → Fivetran → BigQuery → dbt · customer model → Hightouch → Google and Meta Ads. Enrich engagement: CRM and support → Fivetran → BigQuery → dbt · customer model → Hightouch → Braze → Email, push and SMS. Measurement and learning: Web → Tealium EventStream → BigQuery → dbt · customer model → Looker → Outcome analysis.