Data Store templates

Data Store is a built-in NoSQL database designed specifically for server-side Google Tag Manager (sGTM) containers hosted on Stape. To interact with it directly, Stape provides a set of custom GTM templates:

• Stape Store Writer tag – lets you easily write or update data in Data Store.
• Stape Store Lookup variable – allows you to retrieve stored data and put it into your sGTM variables for use across your tags, such as for authentication keys, transaction details, or user attributes.
• Stape Store reStore variable – a versatile template that simultaneously reads and writes data, making it ideal for stitching user profiles across multiple events. It fetches existing records using identifiers from incoming events, merges them with new data, and automatically creates new documents if no match is found, ensuring your session and customer information stays current and up-to-date.

This is the primary template used to save data to the Data Store. It allows you to save incoming event parameters, custom fields, or timestamps into specific database collections. This makes it an ideal solution for building a centralized repository of user interactions, managing API access tokens, or logging tracking data for future use. 

Here's how it works:

1. 1.
   You specify a document key to update or overwrite an existing document.
2. 2.
   You either manually define custom key-value pairs to store only specific, clean data, or you select to capture the entire tracking data sent by the client. This includes standard parameters (whatever is set to receive by your trigger that fires the tag) alongside client-specific metadata (such as GA4's x-ga- parameters).
3. 3.
   When the tag fires, it automatically creates a new document with all information in a specified collection.

This is the primary template used to retrieve and read data from the Data Store without modifying any existing documents. It's ideal when you need to fetch previously saved user properties, configuration details, or attribution data to map directly into your tracking tags.

The variable allows you to target your Data Store collection and look up data in one of two ways:

• You can target a specific document directly by entering its unique document key. This way you request to retrieve that exact document.
• You can filter your collection using query criteria. You can specify conditions (for example, matching a user's email or phone number), and the variable returns the first matching document.

By default, the variable returns the entire retrieved document object. If you only need a specific property (for example, a specific custom field like user_data.email), you can specify a key path in the variable's settings to extract and return only that field.

You'll get the returned value as a variable, which you can then pass to a tag. For example, if a user makes an action on your site that triggers an event (like a webhook) where their email or phone number is missing, you can look up their details using their client_id or session_id. You can then pass this retrieved user data to your Meta Conversions API to maximize match quality.

The reStore variable is the most versatile template: it can write and retrieve data at the same time. It automatically fetches existing data that matches the user's identifiers while simultaneously saving any new information from the event. This makes it ideal for stitching together a user's profile across multiple events.

The variable collects user identifiers from the incoming event (such as email, phone, client ID, or first-party cookies) and checks the Data Store for a matching document that already has one of the identifiers. It then processes the data as follows:

1. 1.
   Merges incoming data with stored data. If a field (for example, phone) is missing from the incoming request but exists in the Data Store, the stored value is used. If the incoming request has a field the Data Store lacks (or has a different value) the request's value is written to the Data Store.
2. 2.
   If no match is found for the user, it automatically creates a new document in the Data Store, laying the foundation for future events.
3. 3.
   The variable returns the resulting “restored” data and it can be easily mapped into your tags.

Here's a quick real world example:

1. 1.
   A user signs up for a newsletter or logs in. Your sGTM container receives their email (for example, user@example.com) along with a first-party cookie (_ga). By configuring the reStore variable to run on this event, you can define the _ga cookie as the user identifier and map the email address as data. When the event triggers, reStore automatically saves this association in the Stape Store.
2. 2.
   Two days later, the same user returns through an ad and browses product pages (view_item events). Although they remain anonymous and don't submit forms or log in, their browser still passes the first-party tracking cookie.
3. 3.
   When the view_item event triggers, the reStore variable executes. It uses the active user's tracking cookie to query the Data Store and instantly locates the document created during their initial login. The variable automatically retrieves the stored email address and makes it available as a variable within your sGTM container.
4. 4.
   You can map this reStore variable directly to your Meta Conversions API tag's User Data fields. This ensures Meta receives the user's email alongside the view_item event, even during anonymous sessions. This significantly boosts your Event Match Quality (EMQ) score and enhances ad performance.