Warehouse-native · Consent-native · Journey-aware
Apolaki is a warehouse-native, consent-native platform being designed to connect acquisition, behavior, identity, and activation, so marketers can understand where customers came from, what influenced them, and what moved them forward. The architecture is designed around the data warehouse you already run, not a vendor database you would have to escape later.
Apolaki is not yet commercially available. It is in planning and architecture validation before the first build cycle.
Apolaki is being planned around four ideas that work together: your warehouse as the system of record, consent attached to every event, a connected view of the customer journey, and compatibility with the systems you already run.
Customer profiles and activation logic are designed around your data warehouse and your data ownership. Snowflake or BigQuery becomes the profile store, not a vendor database behind an export workflow.
Consent state is designed to travel with every customer event and govern downstream activation. Destinations are designed to check consent before delivery, not after.
Acquisition source, campaign context, behavior, identity resolution, and funnel movement are designed to remain connected across the customer journey, instead of scattered across separate tools.
Apolaki is designed to work across websites, CRMs, CMS platforms, LMS platforms, ecommerce systems, advertising platforms, and custom applications, using its own event protocol.
The planned JS SDK target is under 8KB with no dependencies. The install pattern is designed for WordPress, Sitecore, Craft, and custom stacks without changing the event protocol.
The planned agency model supports client workspaces, configurable destinations, and a dashboard that can be handed off without exposing unnecessary implementation details.
The planned control plane includes a live event debugger with event type, name, source, and consent state. It is designed to make QA and client onboarding visible instead of opaque.
Most teams can see an individual event. Fewer can connect it to where the person came from, what they did before, and what happened after, especially once an anonymous visitor becomes a known contact. Apolaki is being designed so that every customer event can help explain where a person came from, what influenced them, what they did next, and how they progressed through the funnel, subject to consent.
The campaign, channel, or source that first brought a visitor in, preserved on the profile as the journey continues.
The campaign and referral context for the current visit, captured alongside the events that happen during it.
The most recent campaign or channel before a conversion, kept distinct from the original first-touch source.
Pages, events, and interactions a visitor generates before they are identified, linked forward once they are.
The profile a visitor becomes after identification, deterministically linked to their prior anonymous activity.
The consent decisions in effect for acquisition and behavioral data, carried alongside the journey, not stored separately.
Where a person sits in a configurable journey, from first visit through to conversion and beyond.
The actions that mark progress for a given business, defined per client rather than assumed.
Apolaki is being designed to help marketers connect activity across funnel stages. Not every organization uses the same funnel, so stage names and conversion events are intended to be configurable per client.
These stages are an example, not a fixed model. Depending on the business, a conversion event might look like an inquiry, an application, a registration, a purchase, a subscription, a renewal, or a re-engagement.
The initial foundation is being designed to support event-level campaign context, session-level acquisition context, and profile-level first-touch and latest-touch history. Multi-touch attribution models, where credit is distributed across every touchpoint, are a planned future capability and not part of the first build cycle.
When an anonymous visitor identifies themselves, for example by submitting a form or logging in, Apolaki is designed to connect their prior acquisition and behavior history to the resulting profile, while preserving consent state and source context. The initial model is deterministic identity stitching, based on identifiers such as email or user ID, not probabilistic matching.
Acquisition and attribution data are not exempt from consent requirements. The planned consent model is designed to capture consent state alongside campaign and behavioral events, govern whether marketing identifiers are retained or activated, and suppress downstream activation when required consent is absent.
These fields are intended to support outcomes such as understanding campaign origin, connecting campaigns to downstream behavior, preserving source context after identity resolution, identifying which channels influence funnel progression, and building audiences from campaign and journey behavior, all without separating consent from the journey.
Teams are being asked to activate customer data while proving consent, reducing vendor lock-in, and controlling platform cost. Apolaki is being planned for teams that want customer data infrastructure they can own, inspect, and extend. Read more about why the market is moving this way.
Marketing teams need clearer proof of what was collected, when it was collected, and whether a destination was allowed to receive it.
More teams already have Snowflake or BigQuery. The customer profile should not be trapped in another system when the warehouse is already the source of analysis.
Usage-based pricing can make routine web and campaign activity expensive. The planned Apolaki model is designed around workspace value, not profile lock-in.
These are architecture targets for the planned platform. They reflect the intended constraints before implementation begins.
Apolaki is a planned warehouse-native MarTech platform. I am collecting feedback from agencies, consultants, and mid-market teams before the first build cycle begins.
Not yet commercially available. The goal is to validate the strongest use cases before implementation starts.
Share your use case