Connect every commerce signal.
Serve the complete customer journey.
Connect events from websites, web applications and native apps with orders, delivery and customer service. Collect and process them under your agreements, so current customer context can serve each connected business service.
For commerce operations, customer experience and digital teams working with IT and privacy owners.
Connected Customer Journeys
One network. Clear agreements for each participant.
A delivery changes, but the service desk sees yesterday's status and a campaign still promotes the delayed product. Each team maintains its own connections and rules. A shared processing agreement lets the same event update the services that need it, with the information each is allowed to use.
Customer
Provides contact preferences and receives updates relevant to the order.
Retailer and service team
Use order commitments, case status and agreed escalation rules.
Fulfilment and delivery partners
Receive the fields needed for their task and return delivery events.
Messaging and digital services
Check purpose and current permissions before a configured communication is sent.
Processes to connect
Bring processing to the data your services already use.
Keep the relevant personal context, purpose, rules and destinations in an approved definition. Connected operations use that definition as new events arrive.
Delivery exception to service action
Route a delay to the responsible team, update the customer channel and prevent a duplicate notification.
Preference change to permitted communication
Apply a changed marketing preference to subsequent configured actions while assessing necessary order messages separately.
Return to consistent follow-up
Connect a return status to support and refund workflows, with approval thresholds and confirmation from the executing system.
Collection is part of the operation
From web and app interactions to business context.
Collection starts where the interaction happens. Define events around your business, then connect accepted information to analytics, service and other permitted outcomes through the same processing agreements.
Websites and web applications
Define product views, searches, filter choices, cart changes, checkout steps and service interactions as business events. Collection JavaScript can be generated from the DimML agreement to check the application data layer before transmitting accepted events.
Native mobile apps
Instrument relevant screen views, product interactions, cart changes and service requests against the agreed event contract. Connect the app to the stream API and validate platform permissions, authentication and delivery behaviour for the selected implementation.
Backend and transaction systems
Combine permitted interaction events with confirmed orders, payments, returns and delivery updates. A checkout click describes an interaction; confirmation from the transaction system establishes the business outcome.
Define the purpose, permitted fields, required context, quality conditions and collection permissions before an event leaves its source. Apply the approved processing and destination rules in the stream. Link sessions or channels only when the identity and purpose conditions allow it. For mobile delivery, explicitly test offline queues, duplicates, late events and a permission change before queued data is sent.
One journey, different permitted outcomes.
A shopper adds an item in a native app and later completes a purchase on the website. Where the approved identity and purpose rules allow the events to be linked, the confirmed order updates the shared context. Analytics can receive the permitted conversion event, customer service can see the relevant order status and a configured cart reminder can be suppressed. Each destination receives the fields allowed for its task.
Example operation
See how an agreement becomes an outcome.
The same input, relevant context and approved rule version produce the same rule-based result. Changed facts or agreements can change the next result, with the applied version recorded.
1. trigger
A delivery partner reports a missed delivery window.
2. context
Match the event to the order, promised date, current support case and the customer's available contact channel.
3. rule
The approved service rule permits a delivery update, shares only necessary fields and escalates compensation above the agreed limit to a person.
4. outcome
Prepare the permitted update and service task. Keep a delivery failure visible for retry or escalation instead of treating a decision as a completed action.
5. evidence
Retain the event reference, relevant context, applied rule version, decision and separate delivery acknowledgement under the agreed retention policy.
Validate late or duplicate events, unavailable destinations and rule changes before activation. Historical evidence explains the earlier decision; a new action must meet the conditions that apply when it is executed.
Rules in context · EU and Netherlands
Turn applicable requirements into explicit processing conditions.
The responsible organisation determines the applicable obligations and approves their translation into executable rules. These sources guide that work; they are not a certification of the solution.
Purpose and lawful use
Specify a lawful basis for each purpose. An order relationship does not automatically authorise marketing. Limit fields and retention to what that purpose needs.
EDPB: legal basisPersonal context with data minimisation
Use the information needed for this service rather than copying a complete customer profile to every partner. Document the purpose and apply approved field and retention rules.
European Commission: GDPR principlesMarketplace obligations where applicable
A marketplace may have DSA obligations that differ from a retailer selling its own products. Establish the service's role and applicable duties before defining the operating rules.
European Commission: DSA and platformsSource review: 20 September 2026. Confirm the applicable requirements for your service and jurisdiction when defining the operation.
Business value
Measure the work you can remove.
Build the business case from the integrations, manual work and evidence preparation this process actually replaces. Include platform fees, implementation, validation and remaining operating costs.
Integration maintenance
Reuse order and permission rules across service endpoints. Measure the hours spent building and changing connections.
Operational reconciliation
Reduce repeated status checks and duplicate case handling. Measure manual touches and resolution time per exception.
Control and evidence
Review the processing decision alongside its delivery result. Measure the time needed to assemble a sample for audit.
Start small, then expand
Prove the value in one bounded process.
Choose one starting point: collect cart and checkout events from one web or native app and connect them to confirmed orders and one permitted destination; or connect delivery exceptions to customer service. Agree the event contract, collection conditions, fields, responsible owner and evidence before activation.
Existing order and fulfilment systems can remain in place. Validate endpoint access, source freshness and delivery acknowledgements. Retire a separate automation only after its required behaviour is covered and tested.
Define your first processAgree the baseline and acceptance criteria
- Time to add or change a web or app event and its destinations
- Incomplete, duplicate or disallowed events detected in validation
- Manual touches and staff time per delivery exception
- Time from source event to accepted service update
- Duplicate or failed notifications and recovery effort
- Connection maintenance, software costs and audit preparation hours
Compare a representative period before and after. Expand only after the responsible owners accept the processing behaviour, evidence and measured value.