Data Store use cases: how it supports your tracking needs

Data Store is a built-in NoSQL database for server-side Google Tag Manager users. It's fast, reliable, and easy to use - you can store and retrieve any type of JSON data without setting up an external database.

While it was originally built to simplify data management inside server containers, companies apply Data Store in many creative ways. To learn everything about this feature, its capabilities, and how to use it to the fullest, check out our detailed guide on Data Store. But in this piece, let's take a look at some of the most common and interesting ways to utilize Data Store, and how you, too, can benefit from it.

Many users choose Data Store as an alternative to Firestore. They use it to store everything from customer data to purchase history (for example, saving all products their clients have bought). There can be different reasons to do so - for instance, Data Store is built directly into the Stape platform, so there's no need for any external setup. You can start saving and reading data immediately inside your sGTM container, without leaving your Stape account.

Some users even purchase Stape's subscription and don't use power-ups, sGTM hosting, or any services other than Store. For them, the Store feature alone is valuable enough to justify the cost!

The main advantage is simpler architecture: instead of provisioning another database, managing credentials, and maintaining an additional integration, teams can use a storage layer that's already part of their Stape-hosted sGTM setup.

Another popular use case is detecting duplicate transactions. Duplicate conversions can inflate your analytics and cause wrong attribution in platforms like Google Ads or Google Analytics. By storing transaction IDs in Data Store, you can easily check if a conversion has already been processed. This setup is handy for server-side tracking with conversions uploaded via APIs.

The same approach can be used for any process that requires deduplication. This includes event IDs, order IDs, lead IDs, webhook IDs, or other unique business identifiers.

Why it's useful:

• Accurate metrics: each transaction is counted only once.
• Better attribution: prevents wrong credit being assigned to multiple channels.
• Smarter budgeting: helps allocate ad budgets based on clean, trustworthy data.

Webhooks automate data transfer between web apps in real time. Some of our clients use Data Store to add extra data to webhooks. This approach ensures your tracking events always include the full context. It works like this:

1. 1.
   When a user performs an online action (e.g., a form submission), you save their cookies or identifiers in the Store under a key such as their email.
2. 2.
   Later, when a webhook event comes in, you look up the same key in the Store, retrieve the user data, and send a complete dataset, including cookies and identifiers, to platforms like Google Ads or Meta Conversions API.

Stape’s Enricher power-up already allows you to enrich event data with user data that was collected earlier. However, when combined with Data Store, you can also enrich events with backend-only data.

Another use for Data Store for data enrichment is to add information that should not or cannot be exposed in the browser, such as CRM status, customer tier, internal product classifications, inventory state, account ownership, margin data, or fulfillment outcomes. The enriched event sent to analytics or advertising platforms carries business context that client-side tracking alone cannot provide.

Cross-domain tracking often breaks because cookies can't be shared between domains.

With Data Store, you can save cookies or identifiers under a shared key (for example, a user ID) and then restore them when the same user lands on another domain. This way, your user data stays consistent, and your analytics can accurately attribute conversions even across different websites.

How it works in practice:

1. 1.
   When a user visits your first domain, you store key tracking data (cookies, session IDs, user identifiers) in Data Store.
2. 2.
   When the same user continues their journey on another domain, the system retrieves the stored data from Data Store using the shared identifier.
3. 3.
   This restored data helps preserve the connection between visits and conversions, ensuring your analytics and advertising platforms recognize that it’s the same user.

The same pattern can extend beyond websites. You can preserve attribution context when a customer moves from a website to a CRM, call center, or other offline process, then recover the relevant identifiers when a backend event or webhook arrives.

Most advertisers measure performance using ROAS (Return on Ad Spend), but ROAS doesn't include product costs. Profit Over Ad Spend (POAS) is a more precise metric. It focuses on actual profit, not just revenue.

Stape already has a dedicated POAS Data Feed power-up that allows you to securely store and retrieve profit data and use it instead of revenue when reporting conversions to Google Ads or Analytics. But Data Store enhances this functionality to allow for more advanced POAS calculations.

For example, profit can depend on SKU, market, discounts, shipping costs, payment fees, commissions, returns, or customer segments. These inputs can be stored server-side and used to calculate a more accurate profit value before sending conversion data to your analytics or advertising platforms.

• Run profit-based bidding while keeping sensitive financial data private.
• Upload conversions in real time without exposing internal numbers.
• Get a more realistic picture of which ads truly drive profit, not just sales.

Click IDs are commonly stored in browser cookies, but cookies can expire, be blocked, become unavailable to backend systems, or otherwise fail to carry attribution data to a later conversion. Data Store provides another place to persist these identifiers.

For example, you can store a click ID against a stable key such as a user ID, session ID, lead ID, or order ID. When a conversion happens later, the click ID can be retrieved using that key and added to the conversion event. This approach still requires a stable identifier that connects the original click with the later event. But it allows attribution data to survive situations where browser-based storage is no longer available.

Finally, Data Store is useful in almost any case where you need to store data temporarily or long-term and then use it later. It's more reliable and scalable than cookies or local storage. All you need is a key to write and retrieve the data, such as a user email, ID, or session token.

• Create documents and collections to hold multiple files.
• Search and filter using conditions. 
• Set TTL (time-to-live) for documents to automatically expire when no longer needed. 
• Retrieve and use data stored in the store to enrich your server-side GTM event flows (e.g., for user attributes, custom parameters, tokens). 
• Use API to programmatically access the store via endpoints.

Standard GTM lookup tables can become difficult to manage when mappings are large, frequently updated, or operationally sensitive. Data Store can hold these datasets instead.

For example, you can store product rules, campaign classifications, regional settings, tenant mappings, or other configuration values. You can then update them through the Stape dashboard, CSV import, or API without republishing the sGTM container every time a value changes.

The same approach can be used to dynamically select destinations, accounts, endpoints, or credentials based on factors such as brand, region, tenant, merchant, event type, or consent state.

Data Store can help connect a user's anonymous activity with their identity and previous actions after they become known. This also makes tracking new and returning customers more reliable.

For example, a visitor may browse your website before logging in or submitting a form. You can store the relationship between their anonymous browser or session identifier and their customer identifier. Once the user becomes known, future events can use that relationship to retrieve approved identity attributes and maintain continuity across previously anonymous sessions.

Consent information is often available in the browser but missing when an event arrives from a CRM, webhook, offline system, or other backend source. Data Store can retain the user's consent state alongside metadata such as its source, timestamp, or policy version.

When a later backend event arrives, the stored consent state can be retrieved before deciding which destinations and parameters are allowed. This helps apply consistent consent rules to non-browser events.

In some cases, standard logs don't retain the request payload or specific fields needed to investigate a tracking issue. Data Store can temporarily hold selected request data in a dedicated collection for debugging.

This approach should be used carefully: apply narrow triggers, short TTLs, data minimization, and PII filtering. Storing every request can create unnecessary privacy risks and quickly consume database write limits.

Data Store has grown from a simple feature into a powerful tool that supports a wide range of tracking and data use cases. With it, you can set up cross-domain tracking, fix duplicate transactions, build a lightweight CDP, or just store data for later use.

Since it's built directly into the Stape platform, there's no need to set up or maintain an external database. You can start saving and retrieving data right inside your server GTM container. Data Store can replace tools like Firestore while keeping everything under one roof.