Dynamic Tap Data (DTD): Personalize Taps by Device and Location
Dynamic Tap Data gives your interactions live context about each tap — the visitor’s phone, operating system, browser, language, and approximate location — usable in messages, redirects, webhooks, and routing.
What is Dynamic Tap Data?
Where a Kitetag Data Structure (KDS) holds data you put on the tag (a name, a SKU, a URL), Dynamic Tap Data is information about the tap itself — derived from each visit as it happens:
- What kind of phone tapped, and which operating system and browser
- The visitor’s preferred language
- An approximate location (country, region, city)
- The time of the tap
You don’t enter any of this. The platform computes it on its servers from each tap, so it’s available to every interaction with nothing to set up.
What DTD values are available
| Value | Placeholder | Example |
|---|---|---|
| Browser | {{ DTD.Browser }} |
Safari |
| Browser version | {{ DTD.BrowserVersion }} |
17.4 |
| Operating system | {{ DTD.OS }} |
iOS |
| OS version | {{ DTD.OSVersion }} |
17.4.1 |
| Device type | {{ DTD.DeviceType }} |
mobile / tablet / desktop |
| Device vendor | {{ DTD.DeviceVendor }} |
Apple |
| Device model | {{ DTD.DeviceModel }} |
iPhone |
| Language | {{ DTD.Language }} |
en-US |
| Country | {{ DTD.GeoCountry }} |
US |
| Region | {{ DTD.GeoRegion }} |
California |
| City | {{ DTD.GeoCity }} |
San Francisco |
| Tap time | {{ DTD.TapTime }} |
2026-05-29T10:14:03-07:00 |
If a value can’t be determined for a given tap, its placeholder simply resolves to nothing — your text won’t show a stray {{ ... }}.
How to use DTD
DTD values work anywhere KDS placeholders do. In the Interaction Builder, the insert-variable picker shows a Tap Data group alongside your tag’s fields — pick a DTD.* value to drop it into:
- Messages — “Thanks for tapping from {{ DTD.GeoCity }}!”
- URL Redirects — build a per-device or per-country destination URL
- Webhooks, Zapier, and Send Email — include device/location context in the payload or email body
- Logic + Data routing — branch the flow on a DTD value (for example, show different content by country)
Powering the App Install step
The App Install step is built directly on DTD: it reads the detected operating system (DTD.OS) and automatically sends iPhone Tappers to the Apple App Store and Android Tappers to Google Play. That routing happens for you — you only choose the apps.
Privacy
DTD is designed to be privacy-respecting:
- Location is approximate — country, region, and city only. It is derived from network information, not GPS, so it never asks the Tapper for permission and never pinpoints them.
- No raw identifiers are stored. The platform keeps only the derived, coarse values (like “iOS” or “California”), not the underlying technical fingerprints.
- Server-derived for trusted uses. Values sent to your webhooks, emails, and integrations are computed on the Kitetags servers so they can’t be faked by a visitor.
Next steps
- Put DTD to work end-to-end with the App Install step.
- Combine DTD with your own tag data fields (KDS).
- Build multi-step flows that use these values in the Interaction Builder.
Last updated 10 Jun 2026, 13:15 -0700 .