Why Apolaki
Customer information is split across websites, analytics tools, ad platforms, CRMs, marketing automation, consent management tools, data warehouses, ecommerce systems, learning platforms, and custom applications. The hard part is not collecting data in any one of these systems. It is preserving the relationships among acquisition, campaign context, behavior, identity, consent, funnel progression, activation, and business outcomes as a person moves across them. Apolaki is being designed to address that architectural gap.
Much of the established MarTech model was built on a set of assumptions: customer data lived inside vendor applications, third-party identifiers were widely available for stitching activity across sites and devices, systems could operate independently of one another, the data warehouse was primarily a reporting destination, and consent was something bolted on after data collection rather than part of it.
Those assumptions have been eroding for several years. Cloud data warehouses have become a central part of many organizations' data infrastructure, first-party data has become a strategic asset rather than a fallback, consent has become an operational requirement rather than a legal afterthought, marketing teams are under more pressure to connect campaign activity to business outcomes, and organizations increasingly want to reuse infrastructure and reduce the number of disconnected systems a customer journey passes through.
This is a gradual, ongoing direction in how MarTech infrastructure is built and bought, not a sudden or universal shift. Many organizations continue to run successful marketing programs on vendor-hosted platforms, and that will remain true for a long time. What has changed is that warehouse-native, consent-aware, and interoperable approaches are now realistic options being evaluated alongside the established ones, in a market that continues to grow quickly: the 2025 marketing technology landscape catalogued 15,384 solutions, up 9% year over year, with nearly 2,500 new tools added in a single year.1
In a vendor-hosted model, customer profile data lives inside the vendor's database. Access typically happens through the vendor's API, export tooling, or reporting interface. This works well for many organizations, particularly when the vendor's destination ecosystem, support model, and pricing fit the team's needs.
An alternative that more organizations are now evaluating is a warehouse-centered model, where the data warehouse the organization already runs, such as Snowflake or BigQuery, holds the customer profile data directly. This is consistent with the broader growth of cloud data warehouse platforms: Snowflake reported a revenue run rate of roughly $3.8 billion in early 2025 with hundreds of customers spending over $1 million annually, and Databricks reported its data warehousing business crossed a $1 billion annual run rate around the same period.2 As more organizations already operate a modern data warehouse for analytics, the question of where customer profiles live becomes less about technical feasibility and more about an architectural choice: portability, the ability to query data directly with SQL, lower friction when changing vendors, reuse of the same data across marketing, analytics, and other teams, and fewer duplicate copies of the same customer record spread across systems.
Apolaki's warehouse-native model is being designed as an option for organizations that already have, or are moving toward, this kind of data foundation. It is not intended as a replacement for vendor-hosted SaaS in general, which remains an appropriate and often simpler choice for many organizations. Apolaki is also planning a hosted model, so that organizations evaluating the platform are not required to already operate or manage their own data warehouse.
In many MarTech stacks today, consent decisions are recorded in one place, such as a cookie consent management platform, a tag manager, a CRM field, or a setting inside an individual channel tool, while the behavioral and profile data those decisions are meant to govern flows through a separate set of pipelines.
This separation creates real risk. Data collected under one consent state can end up being activated later under a different one. A destination receiving an audience or event may not have access to the consent context under which the underlying data was originally collected. Consent history can be difficult to connect back to a specific profile, event, or audience. And audience-building or activation logic may not have a reliable way to check consent before acting.
These risks are not theoretical. Cookie consent enforcement has intensified: European regulators issued some of the largest GDPR fines on record in 2025 specifically over cookie consent practices, including a €150 million fine against a major retailer and a €325 million fine against Google that covered cookie consent issues.3 Separately, Google has required sites serving ads in the European Economic Area to implement Consent Mode v2 since March 2024, a requirement driven in part by the EU's Digital Markets Act.4 Consent has moved from a banner on the page to an operational signal that downstream systems are expected to respect.
Apolaki is being designed around the principle that consent should travel with the event and remain connected to identity, profile history, audiences, and activation, rather than living in a separate system that downstream tools have to look up independently. This is not a legal guarantee of compliance with any particular regulation. The initial architecture supports recording consent state alongside customer events and is designed to help organizations operationalize consent-aware activation and maintain an auditable record of what consent state applied to a given event or destination delivery.
Marketers cannot evaluate how campaigns influence funnel movement if the context of how a visitor arrived disappears after the landing page. That context includes UTM source, medium, campaign, term, and content; the landing page and referring source; campaign identifiers; ad click identifiers where consent and platform rules permit; session-level, first-touch, and latest-touch context; and the conversion events that mark progress for a given business.
Apolaki is designed to connect this context across a configurable journey:
These stages and their funnel definitions are intended to be configurable per organization. Depending on the business, a conversion event might be an inquiry, an application, a registration, an enrollment, a purchase, a subscription, a renewal, or a re-engagement.
Preserving UTMs, referrers, and click identifiers does not by itself produce complete attribution. Attribution is constrained by privacy rules, consent state, cross-device behavior, advertising platform restrictions, offline interactions, incomplete identifiers, and walled-garden reporting. Roughly four in ten marketers cite the lack of data from walled gardens as a measurement problem, and advertisers typically receive only aggregated, platform-curated metrics with no cross-platform view of the customer journey.5 No platform, including Apolaki, can fully resolve these constraints. Reliable attribution starts by preserving the available journey evidence consistently and connecting it to identity and consent, not by promising a complete or perfect picture of every touchpoint.
Apolaki's initial identity model is designed around a deterministic sequence:
A visitor arrives through a campaign, referral, or direct visit.
Apolaki records the permitted acquisition and behavioral context for that visit.
The visitor returns, or continues through the funnel, generating further anonymous activity.
The visitor identifies themselves through a form submission, login, purchase, application, registration, or another deterministic signal such as an email address or user ID.
Prior permitted activity is connected to the resulting known profile.
Consent state and acquisition source history remain attached to the profile through this transition.
The resulting profile supports analysis, audience building, and activation, subject to consent.
This initial model is deterministic identity stitching, based on identifiers such as email addresses or user IDs that a visitor provides directly. It does not rely on probabilistic matching, fingerprinting, or inferred identity. Probabilistic identity resolution is not part of the initial design.
Most organizations already run multiple marketing, sales, and data systems, and that number continues to grow: the marketing technology landscape now spans nearly 50 categories and over 15,000 products.1 At the same time, research consistently finds that marketers use only a fraction of the capabilities already available to them. Gartner found marketers used about a third of their stack's capability in 2023, down from over half in 2020, and a 2025 survey found that 99% of marketers report unused capabilities in their stack, with most using only half to three-quarters of available features.6
Apolaki is not intended to replace every CRM, CMS, learning management system, ecommerce platform, analytics tool, advertising platform, email provider, or data warehouse an organization runs. The intent is to create a shared customer-data and consent layer across these systems, so that the data and consent context generated in one system can be made available to the others without each pair of systems needing its own custom integration.
The planned model for this is system-agnostic: a browser SDK, server-side SDKs, a REST API, webhooks, destination connectors, and direct warehouse integration, all producing the same underlying event and consent model regardless of which system the data originated from or is being sent to.
Most of the individual capabilities described on this page already exist somewhere in the market. Warehouse-native data models, consent management platforms, identity resolution, campaign tracking, and reverse ETL tools are all established product categories, each delivered through separate products, separate data stores, and separate control models.
The opportunity is not that no one else is addressing these problems. It is that combining these principles coherently, in a single architecture, is still uncommon for organizations that need all of them together: warehouse-native data ownership, consent attached to events and activation, deterministic identity continuity, preserved campaign and journey context, collection that works across many kinds of systems, a deployment model that is practical for mid-market organizations and agencies, and an architecture that a small team can operate without a dedicated platform department.
Apolaki is being designed as a focused response to that intersection, for organizations that find themselves needing several of these things at once rather than any single one in isolation.
Several trends make this a reasonable time to pursue this direction. Cloud data warehouses are more accessible than they were a few years ago, and many organizations' customer data is already centralizing there for analytics purposes. First-party data has become strategically important on its own terms: a 2024 Forrester Consulting study found organizations using first-party behavioral data reported improvements in customer acquisition cost, satisfaction, and conversion, and separate research found that 84% of marketers rely on first-party or transactional data for audience insights.7
Privacy and consent requirements now affect day-to-day marketing operations, not just legal review. Marketing and leadership teams face increasing pressure to demonstrate measurable outcomes from campaign spend. Organizations want more control over their data and their integrations, partly in response to vendor lock-in and rising platform costs. Modern APIs and cloud infrastructure make it more practical to build and operate a leaner, more focused platform than it would have been a decade ago.
AI-assisted development is also part of this picture, but as an enabling factor rather than the reason Apolaki should exist. AI tooling lowers the cost of building and maintaining specialized software, which makes a more narrowly scoped, architecturally opinionated platform more feasible for a small team to build and support. It does not replace the governance, data modeling, and engineering discipline the platform still requires.
Apolaki is pre-build. The distinctions below separate what is currently designed, what is being built first, and what is a future direction. Future capabilities are not implied to exist today.
Event collection, campaign and acquisition context, consent state attached to events, deterministic identity resolution, profile history, destination connectors, audiences, warehouse integration, and a control plane. This is the first planned build cycle.
Standalone contact and pipeline management that can run on its own, and becomes stronger when connected to CDP profiles. Planned to be built only after the CDP foundation is established.
Configurable funnel analytics, multi-touch attribution, journey scoring, email automation, personalization, expanded consent management, and AI-assisted scoring and decision support, planned after the CDP and CRM foundations.
Apolaki is being built from a practical observation: organizations should not have to choose between data ownership, usable marketing activation, journey understanding, and consent enforcement. The platform is an attempt to bring those concerns into one coherent architecture. It will be validated incrementally, through working software, design-partner feedback, and real implementation requirements, not assumed in advance.
If you are a marketer, MarTech leader, agency, data leader, advisor, or potential design partner, I would like to hear how you currently handle customer data, consent, attribution, and activation.
Apolaki is not yet commercially available.
Share your use case