Platform
Apolaki is planned as two products on one data layer: a warehouse-native CDP first, followed by a CRM that can work standalone and becomes stronger when paired with the CDP. The data layer is designed to carry acquisition and journey context through to identity, the warehouse, and activation.
Apolaki is not yet commercially available. The roadmap describes intended sequencing, not current product availability.
Apolaki is in planning and validation. The first planned build cycle is the CDP foundation. CRM is planned only after the CDP foundation is solid.
Customer data platform planned for your warehouse.
Apolaki CDP is being designed to collect events from browser, server, and REST sources. The planned identity layer resolves anonymous and known activity into a single profile, then makes that profile available for warehouse-native activation. Profiles are intended to live in Snowflake or BigQuery, not in a proprietary Apolaki profile database.
The identity engine is planned around seven resolution cases: new anonymous visitors, anonymous-to-known stitching, known profile merges, trait updates, merge chains, and conflict resolution. Cross-tenant isolation is a required design constraint.
The planned event model is designed to carry campaign and acquisition context alongside behavior, so that when anonymous-to-known stitching connects a visitor to a profile, their acquisition history and first-touch and latest-touch context move with them.
This is the intended path for acquisition and journey data, from the channels that bring people in through to the warehouse and activation. The seven-layer pipeline below shows the detailed version of the same flow.
The planned connector tiers all produce the same event envelope and attach consent before events enter the pipeline.
Target: under 8KB with no dependencies. Planned capture includes pageviews, anonymous ID, session context, and consent state from OneTrust and GTM dataLayer.
Planned PHP, Python, and Node.js SDKs for purchase events, authentication events, server-side identify calls, and batch imports. Same event envelope as the browser SDK.
Planned REST API for systems that can make a POST request, including Zapier, CRM webhooks, legacy applications, and batch imports. Write key authentication and queue dispatch are part of the design.
The planned event path moves from collection to destination with consent checked at the points where data changes state or leaves the platform.
| # | Layer | What it does |
|---|---|---|
| 1 | Connector | JS SDK, server SDKs, and REST API. All planned to output the same event envelope, including campaign and UTM parameters where present |
| 2 | Ingestion | Validates events, authenticates write keys, attaches consent state, dispatches to queue |
| 3 | Pipeline | Enforces schema, enriches context, gates on consent, fans out to identity and destination queues |
| 4 | Identity engine | Resolves anonymous to known, merges profiles, updates trait store, and carries acquisition and behavior history forward into the merged profile |
| 5 | Profile store | Postgres for live reads and writes, Snowflake for batch and warehouse queries, including first-touch and latest-touch acquisition history |
| 6 | Activation | Audience builder, computed traits, destination sync, reverse ETL, including audiences built from journey and campaign behavior |
| 7 | Control plane | Dashboard for sources, destinations, live event debugger, profile viewer, and consent log |
Contact and pipeline management planned after CDP foundation.
Apolaki CRM is planned as a contact, account, deal, and pipeline layer that can work standalone. It is intentionally sequenced after the CDP foundation, not before it.
When paired with the CDP, each CRM contact is intended to connect to a full behavioral profile from the warehouse. The goal is to show page visits, event history, and audience membership alongside deal data in the same view.
Planned: contacts, accounts, deals, pipeline stages, activity log, and email integration.
Planned: full behavioral profile per contact, audience-driven views, and pipeline changes that trigger CDP events.
Apolaki is being planned for teams that want warehouse-native profiles, consent-aware activation, and a practical path from CDP to CRM.
| Capability | Planned Apolaki | Segment | RudderStack | Hightouch |
|---|---|---|---|---|
| Profiles in client's warehouse | ✓ | ✗ | Partial | ✓ |
| Consent on every event record | ✓ | ✗ | ✗ | ✗ |
| Flat workspace pricing | ✓ | MTU-based | Event-based | Row-based |
| Agency white-label | ✓ | ✗ | ✗ | ✗ |
| CRM included | ✓ | ✗ | ✗ | ✗ |
| Own event protocol | ✓ | Proprietary | Segment-compatible | n/a |
| Acquisition and journey context linked to identity | ✓ | Partial | Partial | ✗ |
10 to 50 staff managing multiple client MarTech stacks. The cost per client on existing CDPs adds up fast. The planned model supports separate workspaces per client and an agency-friendly handoff.
Independent consultants and fractional CTOs who need a CDP they can eventually set up for a client in a week, not a quarter. The planned platform emphasizes a clean API surface and self-serve workspace provisioning.
FERPA-aware institutions with lean teams and budgets that do not support six-figure enterprise software. The planned data model treats consent as a first-class field from day one.
Organizations that need contact management first and an event pipeline later. The CRM is planned to work on its own, then become stronger when connected to the CDP.
Apolaki is pre-build. The roadmap below explains intended sequencing, not current product availability. Read the product rationale for the market context behind this sequencing.
Architecture, event model, consent model, connector strategy, data schema, and early customer discovery.
Laravel API, 10-table schema, write key authentication, event ingestion, SQS dispatch, consent-aware event envelope, campaign and acquisition context, deterministic identity resolution, profile history, and first-touch and latest-touch acquisition.
Anonymous-to-known stitching that carries acquisition and behavior history into the merged profile, profile merge rules, destination connectors, delivery audit logs, and live event debugging.
Contacts, accounts, deals, pipeline stages, activity log, and CDP-backed profile context when the CDP is enabled.
Configurable funnel analytics, multi-touch attribution, campaign performance analysis, journey scoring, and AI-assisted next-best action, planned after the CDP and CRM foundations and not part of the first build cycle.
I am collecting feedback before the first build cycle. Share the CDP, consent, CRM, or activation problem you are trying to solve.
Apolaki is not yet commercially available.
Share your use case