
Zero-Retention Personalisation: How to Personalise High-Privacy Journeys with Adobe Target Server-side

Recently, one of our financial services clients approached Dexata team with a rather interesting challenge: zero-retention personalisation. They were launching a high-intent, digital-first mortgage affordability calculator designed to help prospective buyers estimate their borrowing.
Their marketing team wanted to deliver tailored advice, dynamic rate tiers, and relevant next-best-action banners. They aimed to personalise content based on real-time inputs like household income and deposit size. However, the risk and compliance team had a strict mandate: no sensitive financial data could be stored, profiled, or tied back to a persistent visitor profile. This rule applied strictly to unauthenticated users exploring options anonymously. Furthermore, they needed to cater to visitors who opted out of targeting cookies on the gateway page.
Standard client-side personalisation relies on client-side JS libraries and the Experience Cloud ID to stitch historical visitor data. This traditional approach was completely out of the question.
Dexata solution? We engineered a zero-retention personalisation architecture using Adobe Target Server-Side Delivery REST APIs. By evaluating context purely at the hit level, we delivered real-time, context-aware experiences. We ensured zero sensitive data was retained on the user or in Adobe Target’s long-term profile database.
Through this article, we are sharing how we built the solution and hope you can implement the same architecture for your high-privacy digital journeys.
Architectural Freedom: Zero Adobe Libraries Required
One of the biggest misconceptions in the Adobe based MarTech ecosystem is that you need an Adobe SDK, whether that is client-side (at.js, Web SDK) or server-side (Node.js, Java, Python SDKs) to run Adobe Target.
You do not need a single line of Adobe client-side JavaScript or server-side SDK code.
Because the Adobe Target Delivery API is a pure RESTful interface, your backend application (whether built in Node, Python, .NET, Go, or PHP) simply dispatches standard HTTP POST requests directly to Adobe’s Edge endpoints.
Why Going “Library-Free” Matters for High-Privacy & Performance:
Zero Client-Side Footprint: No JavaScript libraries loaded in the user’s browser, eliminating client-side flicker, DOM mutations, and third-party script vulnerabilities.
Bypasses Cookie & Tag Blockers: Because the handshake occurs purely server-to-server, ad-blockers and privacy extensions cannot block the request or inspect the payload.
Total Payload Control: Your engineering team retains 100% control over every byte sent over the wire. You decide exactly what parameters are transmitted and ensure no auto-collected browser identifiers leak through.
Zero Dependency Overhead: You don’t have to manage SDK lifecycle updates, breaking library changes, or heavy server-side dependency packages.
Commercial Impact: Some use-cases
When we think of personalisation, we usually think of a deep, historical profile: what a user bought last month or their multi-device browsing journey. But in specific scenarios, persistent tracking introduces major compliance risks and consumer friction.
Beyond financial tools, here are some other practical business use cases where a zero-retention personalisation comes handy:
Anonymous Healthcare Symptom Checkers: Tailoring specialist recommendations based on real-time symptom selections without storing sensitive health inputs in a marketing database.
Consent-Gated Gateways: Delivering geo-targeted homepages to visitors who explicitly rejected performance and targeting cookies during CMP banner interactions.
Multi-Step Funnel Continuity: Personalising a multi-step quote form where Page A serves a tailored offer and Page B tracks completion, destroying all tracking state as soon as the active tab is closed.
Architectural Paradigms: Hit-Scope vs. Ephemeral Session
To implement zero-retention personalisation server-side, you must understand how Adobe Target handles identifiers:
According to the official Adobe Target Delivery API Specification, the sessionId is a required string parameter (1 to 128 characters) used to route requests to the correct edge cluster node.
If you generate a new
sessionIdfor every request, Target treats each hit as an isolated, stateless event (Hit-Scope).If you reuse the same
sessionIdduring a single user journey, Target correlates events within that 30-minute window without creating a long-term profile (Ephemeral Session).
To decide between a Hit-Scope or an Ephemeral Session pattern, ask yourself one simple question: Does the experience on Page B need to know that the user interacted with Page A?
1. Pure Hit-Scope (Stateless) Scenarios
In a Pure Hit-Scope pattern, every single API request generates a brand-new random sessionId (e.g., UUID_001 for request 1, UUID_002 for request 2). Target evaluates the request, returns the payload, and instantly forgets the context.
Scenario A: Anonymous Financial & Mortgage Calculators
The Goal: A visitor enters sensitive financial data (gross income, monthly expenditure, debt levels) into an interactive loan calculator.
The Personalisation: You want to dynamically display targeted interest rates or relevant advice cards based strictly on those real-time calculation values.
Why Hit-Scope: Storing household income or loan sizes in a persistent or session-based marketing profile introduces immense data protection compliance risks. With Hit-Scope, Target evaluates the parameters in-memory to pick the right variant, then discards the data the millisecond the HTTP response closes.
Scenario B: Strict CMP/Consent-Gated Gateways
The Goal: Personalise high-level landing pages for visitors who have explicitly opted out of marketing cookies or profiling via your Consent Management Platform (CMP).
The Personalisation: Delivering localized branch information, device-optimized content, or current weather/promo banners using request headers (IP/Geo, User-Agent) or page URL parameters.
Why Hit-Scope: Because the user rejected tracking cookies, you cannot read or set a persistent
tntIdorECID. Hit-Scope satisfies legal mandates by executing real-time content decisioning server-side without leaving a trace or tracking the user across pages.
2. Ephemeral Session (In-Flight) Scenarios
In an Ephemeral Session pattern, your backend maintains the same random sessionId across multiple requests during a single user journey (e.g., passing UUID_SESSION_X from Page 1 to Page 3). The session stays active in Adobe Target’s edge memory for its default 30-minute window, but no persistent profile (tntId or ECID) is ever saved to disk or written to a browser cookie.
Scenario A: Multi-Step Quote & Application Funnels
The Goal: A customer begins a 4-step car insurance quote funnel. On Step 1, they select “Electric Vehicle.”
The Personalisation: On Step 3 (Coverage Options), you want to dynamically feature “EV Battery Protection” based on their selection back in Step 1.
Why Ephemeral Session: Step 3 needs memory of Step 1’s selection within that specific application attempt. Passing the same
sessionIdkeeps the state alive in Target’s in-memory edge cluster. The instant the tab is closed or 30 minutes elapse, the session expires and all temporary context vanishes.Adobe Developer+ 1
Scenario B: Server-Side Conversion Attribution
The Goal: You serve a personalised hero banner on Page A (e.g., promoting a specialised credit card) and want to measure whether it drives completed applications on Page B (the thank-you page).
The Personalisation: Evaluating a server-side A/B test or Experience Targeting activity.
Why Ephemeral Session: To log a conversion back to the original test variant without using client-side analytics tags, your server sends a
notificationsAPI payload on Page B. Reusing the samesessionIdensures Target maps the conversion on Page B to the impression served on Page A, keeping your test results accurate without tracking the user post-journey.
Implementation:
As you would agree, personalisation doesn’t stop after rendering the personalised experience. We also need to assess how the experience performed against the key business metrics. Proving value of Personalisation should be one of the key responsibilities of any MarTech team and that’s why implementing zero-retention personalisation requires two steps:
Step 1: Execute Personalisation (HTTP POST Request)
To fetch an isolated experience directly from your backend server using a basic HTTP client (e.g., fetch, axios, cURL), make a POST request to the Target Delivery endpoint.
Below is a clean payload structure designed to pass current page details and custom in-the-moment parameters without passing any user IDs.
// HTTP
POST https://<YOUR-CLIENT-CODE>.tt.omtrdc.net/rest/v1/delivery?client=<YOUR-CLIENT-CODE>&sessionId=<TRANSIENT-SESSION-ID>
// JSON
{
"context": {
"channel": "web",
"address": {
"url": "https://dexata.co/tools/mortgage-calculator"
},
"userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)...",
"screen": {
"width": 1920,
"height": 1080
}
},
"execute": {
"mboxes": [
{
"name": "anonymous-calculator-hero",
"index": 1,
"parameters": {
"loan_amount": "450000",
"applicant_type": "first_time_buyer"
}
}
]
}
}
Critical Rules for Zero-Retention Architecture:
Omit the
idBlock: Never pass theidobject (which typically housestntIdormarketingCloudVisitorId). When omitted, Target evaluates the experience based purely on thecontextandparameterssupplied in this specific request.Discard Identifiers: In its response, the Target Edge will generate and return a
tntIdfor bucketing purposes. Your backend server must discard this ID. Do not write it back to a cookie or save it in a database.Target via In-Memory Audiences: In the Adobe Target UI, ensure your targeting criteria use “Mbox Parameters” or “Current Page” context rather than persistent “Visitor Profile” attributes.
Best Practices for Managing Session Ids: Managing session IDs effectively is what bridges the gap between strict privacy enforcement and smooth multi-page personalisation. When working with the Adobe Target Delivery API, generating and maintaining the sessionId is entirely your server's responsibility. Target uses this string to route requests to the same edge cluster node, where temporary in-memory profile evaluations take place. Here are the technical best practices for generating, formatting, and persisting ephemeral session IDs across pages without leaving a long-term data footprint. 1. Generation & Formatting Rules: Adobe Target enforces specific formatting constraints for the sessionId query parameter.Key Specifications:
- String Length: Must be between 1 and 128 characters.
- Forbidden Characters: Cannot contain spaces, question marks (?), forward slashes (/), or curly braces ({ }).
- Format Standard: Cryptographically secure v4 UUIDs (e.g., f47ac10b-58cc-4372-a567-0e02b2c3d479) or high-entropy random hex strings are ideal.
import { randomUUID } from 'crypto';
/** * Generates an Adobe Target compliant, ephemeral Session ID */
export function generateTargetSessionId(): string {
// Standard v4 UUID (36 chars, fully compliant)
return randomUUID();
} 2. Best Practices for Saving Session IDs Across Pages To keep personalisation active across a multi-step journey (e.g., Page A to Page B) without persisting a long-term tracking profile, you can use three stateless/ephemeral persistence methods:
- Ephemeral HTTP-Only Cookies: Set a temporary, short-lived session cookie managed entirely by your application backend.
- URL Query Params or Post Payloads: Encrypt the sessionId string within an application state token (e.g., a signed JWT) and pass it in internal form POSTs or URL query params between Page A and Page B.
- Server-Side Session Memory: Store the sessionId in an in-memory server cache (like Redis or Memcached) tied purely to an active application request lifecycle.
Step 2: Measuring Performance & Conversion Analytics
When you strip out persistent identifiers like the ECID, standard client-side analytics stitching breaks. However, you can still measure personalisation experience performance without compromising user anonymity. You have two primary technical routes depending on your analytics stack:
Option A: Native Adobe Target Reporting (Target-Only Route)
If you want to track conversions on a secondary page (e.g., an application confirmation page) directly within Adobe Target, use the Adobe Target Delivery API Notifications Endpoint.
Instead of an execute block (which evaluates a new experience), your server sends a stateless notifications POST request using the same transient sessionId:
// http
POST https://<YOUR-CLIENT-CODE>.tt.omtrdc.net/rest/v1/delivery?client=<YOUR-CLIENT-CODE>&sessionId=<TRANSIENT-SESSION-ID>
// JSON
{
"context": {
"channel": "web",
"address": {
"url": "https://dexata.co/tools/mortgage-calculator/success"
}
},
"notifications": [
{
"id": "10001",
"type": "click",
"timestamp": 1780843200000,
"mbox": {
"name": "calculator-conversion-success",
"parameters": {
"lead_type": "qualified_mortgage"
}
}
]
}
}
Option B: Adobe Analytics for Target (A4T) via Server-Side Data Insertion
If your organisation relies on Adobe Analytics for Target-based activity reporting, you can still leverage Analytics for Target (A4T). Because you lack a client-side ECID, your server acts as the data router between Target and Analytics.
1. Request Client-Side Logging Flags in Target
Add "logging": "client_side" to your Target Delivery payload. This instructs Target Edge not to forward tracking automatically, but to return a cryptographic A4T token string in the API response:
"analytics": {
"payload": "pe=tnt&tnt=294715:0:0|2,294715:0:0|1"
}
2. Forward Token to the Adobe Analytics Data Insertion API
Your server then programmatically forwards this token to Adobe Analytics via the Data Insertion API, mapping the transient sessionId as a temporary visitor ID:
Add "logging": "client_side" to your Target Delivery payload. This instructs Target Edge not to forward tracking automatically, but to return a cryptographic A4T token string in the API response:
<?xml id="1.0" encoding="UTF-8"?>
<request>
<reportSuiteID>dexata_privacy_report_suite</reportSuiteID>
<visitorID>transientSession123_abc456</visitorID>
<pageName>Tools: Mortgage Calculator</pageName>
<timestamp>2026-07-25T11:42:00Z</timestamp>
<!-- Injected cryptographic A4T payload string -->
<queryString>pe=tnt&tnt=294715:0:0|2</queryString>
</request>
Helpful Technical & Documentation References
To explore library-free server-side personalisation and delivery API capabilities further, review these official Adobe resources:
API Endpoint Specification: Adobe Target Delivery API Reference Guide
Event Tracking & Measurement: Adobe Experience League: Delivery API Notifications Documentation
Architecture Overview: Adobe Experience League: Target Server-Side Overview
Conclusion
In our client’s case, moving to hit-scope server-side personalisation without client-side or server-side libraries unlocked a 32% increase in calculator completion rates, while completely satisfying their strict legal and compliance risk frameworks.
Decoupling personalisation from long-term tracking allows you to respect user privacy while continuing to deliver relevant, high-converting digital experiences. By mastering both hit-scope and ephemeral session-scope patterns via Adobe Target’s Delivery API, you can satisfy data protection compliance while hitting your business conversion goals.
Dexata helps enterprise marketing teams design and execute Adobe Target architectures that turn personalisation capabilities into measurable revenue growth. If you want to unlock higher conversion rates from your current setup, , contact us.
Get Your MarTech Value Audit
Identify underutilised capabilities and high-impact optimisation opportunities.