Thanx Loyalty Tracking: The Complete GTM and GA4 Guide for Restaurants (2026)

Thanx is one of the most data-rich loyalty platforms a restaurant can run, and that is exactly why so many Thanx setups are tracked badly. The platform captures purchase behavior automatically through card linking, which means the moments worth measuring, enrollment, reward unlocks, and redemptions, do not happen the way a normal web form does. If you track Thanx like a standard sign-up flow, you will overcount enrollments, miss redemptions that happen at the counter, and never connect a member to their spend.

This guide fixes that. It covers what Thanx actually is and how its two loyalty models work, then gives you a correct, copy-paste Thanx loyalty tracking setup for Google Tag Manager and GA4, including the card-linked timing fix that almost every implementation gets wrong. Everything here works alongside your ordering tracking and slots into the same measurement model, so loyalty and orders finally describe the same guest.

What is Thanx and how does it work?

Thanx is a guest engagement, loyalty, and CRM platform built for restaurants. Where most loyalty programs rely on punch cards or app check-ins, Thanx is built around credit card tokenization: when a guest links a card, their purchases are tracked automatically with no scanning, no app to open at the counter, and no code to enter. That automatic capture is the whole point, because it produces clean purchase data that powers segmentation and lifecycle marketing rather than just a points balance.

The platform also takes a deliberate stance on rewards. Instead of blanket discounts that erode margin, Thanx leans on access, exclusivity, and personalized perks, the kind of rewards that drive repeat visits without training guests to expect a coupon. For tracking, that distinction matters, because the events you care about are reward unlocks and redemptions tied to real spend, not discount giveaways.

Card-linked loyalty versus check-in loyalty

Thanx offers two enrollment models, and which one a restaurant uses changes how you track it. Card-linked loyalty tracks purchases automatically once a guest registers a payment card, so enrollment and the first purchase often happen in the same moment. Check-in loyalty uses QR codes, phone-number lookup, and native POS integrations, so enrollment is a more visible, discrete action. The tracking code is the same either way, but the firing point differs, and the card-linked model is the one that trips people up, which we cover in detail below.

What are the key Thanx features?

The CRM and segmentation tools let you group guests by spend, frequency, and churn risk. The Winback engine uses machine learning to re-engage lapsed guests automatically. Lifecycle automation runs the campaigns that move a guest from first visit to regular. And because credit card tokenization captures purchase data accurately, the segments are built on real behavior rather than self-reported preferences. Each of these features generates signals worth tracking, but the highest-value ones for analytics are enrollment, reward redemption, and the spend tied to a member.

What integrations does Thanx support?

Thanx integrates natively with the major ordering and POS systems restaurants already run, including Olo, Toast, Square, and Deliverect. With Olo specifically, loyalty enrollment can happen directly inside online ordering, and a large share of digital purchasers get enrolled into the CRM automatically at checkout. For tracking, these integrations matter because the enrollment and purchase events you want to measure often originate inside the ordering flow, which means your Thanx loyalty tracking and your ordering tracking need to share one consistent measurement model.

How is Thanx different from other restaurant loyalty platforms?

Knowing where Thanx sits helps you track it correctly, because the differences are behavioral, not just feature lists.

The takeaway for tracking: Thanx and Toast both use card-linked enrollment, which means enrollment completes at payment rather than on a click. Square uses phone-number enrollment, which is a discrete action. Recognizing which model you run tells you exactly where to fire the enrollment event, and getting that wrong is the single most common Thanx tracking error.

Why is tracking Thanx loyalty different from other platforms?

There is a second difference. Thanx captures purchase data through card tokenization on the server side, and some loyalty events, a reward unlocking after a qualifying visit, a redemption at the physical counter, happen after the browser session has ended. Those cannot be captured by a client-side dataLayer push at all. They need server-side tracking, which we cover further down.

Which Thanx loyalty events should you track in GA4?

The same recommended-event mapping that works for any loyalty program works for Thanx, and using recommended events instead of custom ones gives you GA4 reporting for free. Thanx reward progress behaves like an in-app currency, so it maps cleanly to GA4’s virtual-currency events.

How do you set up Thanx loyalty tracking with the dataLayer?

This is the universal layer, written for the Thanx firing points. It is plain JavaScript with no dependencies. Call each function from the right Thanx callback, which for card-linked enrollment means the transaction-complete handler, not a button click.

// ============================================================
// Thanx Loyalty dataLayer for GTM + GA4
// No dependencies. Fire from the correct Thanx callbacks.
// ============================================================
window.dataLayer = window.dataLayer || [];

// 1. ENROLLMENT  ->  GA4 sign_up
// IMPORTANT: call this on the TRANSACTION-COMPLETE callback for a
// guest's FIRST qualifying purchase, not on a sign-up button.
// isFirstPurchase prevents double-counting auto-enrolled guests.
function trackThanxSignup(memberId, isFirstPurchase) {
  if (!isFirstPurchase) return;            // dedupe: only the first time
  window.dataLayer.push({
    event: 'thanx_signup',
    loyalty_method: 'card_linked',
    loyalty_program: 'Thanx',
    loyalty_id: memberId                   // non-PII Thanx member ID
  });
}

// 2. MEMBER SIGN-IN  ->  GA4 login
function trackThanxLogin(memberId) {
  window.dataLayer.push({
    event: 'thanx_login',
    loyalty_method: 'thanx',
    loyalty_program: 'Thanx',
    loyalty_id: memberId
  });
}

// 3. REWARD UNLOCKED  ->  GA4 earn_virtual_currency
function trackThanxRewardEarned(rewardName, progressValue, tier) {
  window.dataLayer.push({
    event: 'thanx_reward_earned',
    points_currency_name: 'thanx_reward',
    points_value: progressValue,           // e.g. 1 reward, or $ progress
    reward_name: rewardName,               // 'Free Entree'
    loyalty_tier: tier
  });
}

// 4. REWARD REDEEMED  ->  GA4 spend_virtual_currency
function trackThanxRewardRedeemed(rewardName, rewardValue, tier) {
  window.dataLayer.push({
    event: 'thanx_reward_redeemed',
    points_currency_name: 'thanx_reward',
    reward_value: rewardValue,             // value applied to the order
    reward_name: rewardName,
    loyalty_tier: tier
  });
}

// 5. MEMBER IDENTITY  ->  set once on sign-in / page load
// Lets GA4 attribute every purchase to the member for LTV.
function setThanxMember(memberId, tier) {
  window.dataLayer.push({
    event: 'set_loyalty_user',
    loyalty_id: memberId,                  // also set as GA4 user_id
    loyalty_member: true,
    loyalty_program: 'Thanx',
    loyalty_tier: tier
  });
}

How do you configure GTM for Thanx tracking?

The GTM side is identical to any loyalty setup, because the container listens for event names rather than anything Thanx-specific. You need one Constant variable for your GA4 Measurement ID, Data Layer Variables for the loyalty fields, Custom Event triggers for each Thanx event, and GA4 Event tags that forward each one.

Rather than reprint the full container here, use the importable one in our restaurant loyalty tracking guide. It is vendor-agnostic and works for Thanx as-is. Import it with the Merge option, set your Measurement ID in the single Constant variable, and then point the triggers at the Thanx event names. The mapping is one trigger per event:

If you would rather keep Thanx fully self-contained, duplicate each tag and trigger in that container and rename the trigger event names to the thanx_ versions above. Either way, set the GA4 user_id field on your Google Tag to the Thanx member ID variable so member attribution works.

Should you put Thanx tracking in the same GTM container as Olo?

Yes, in almost every case. Keep loyalty and Olo tracking in one container and import the loyalty config with the Merge option. One container means one source of truth, one set of shared variables, one consent configuration, and one place to debug when something fires twice. It also makes the collisions in the next section easy to see, because every tag and trigger sits in the same workspace.

A second container is the wrong default. It loads a second gtm.js on the page, which is the fastest way to end up with duplicate page_views and double-fired events, and it splits your debugging across two interfaces. The only time you genuinely run two containers is when your Olo ordering lives on an Olo-hosted domain that carries its own container. In that case the split is unavoidable, and you stitch the two sides together with cross-domain measurement and a shared member ID, exactly as described below. For everything else, one merged container is cleaner and safer.

How do you add Thanx tracking without breaking your Olo tracking?

This is the part most advertisers and analytics teams get wrong, and it quietly corrupts data for months before anyone notices. Your Olo setup already fires a complete GA4 ecommerce sequence, including a purchase event with revenue. Bolt loyalty tracking on top carelessly and you double-count revenue, inflate users, or split one guest into two. Here are the five collisions and how this setup avoids each one.

Two structural safeguards make this work. First, every loyalty trigger is a Custom Event set to EQUALS on an exact event name, so a loyalty tag can never fire on one of Olo’s ecommerce events, and an Olo tag can never fire on a loyalty event. Second, every loyalty dataLayer push includes all of its own parameters rather than relying on values left behind by a previous push, which prevents a loyalty event from reading a stale revenue or currency value that Olo set earlier in the session. Keep both habits and the two systems run side by side cleanly.

How does Consent Mode v2 affect Thanx and Olo tracking together?

If your restaurant serves guests in the EEA or the UK, Consent Mode v2 is not optional, and it has to be applied consistently across both your loyalty tags and your Olo tags. The failure mode is subtle: if your Olo tags wait for analytics consent but your loyalty tags fire regardless, you collect loyalty events for guests who never appear in your ordering data, and your member-versus-non-member comparison ends up built on two different consent populations.

The fix is to treat both sets of tags the same way. Set your consent defaults to denied before GTM loads, update them when the guest makes a choice through your consent banner, and make sure every loyalty tag requires analytics_storage just like your Olo tags do. The loyalty container ships with consent settings left open so it inherits your container’s additional consent checks rather than overriding them, which keeps loyalty and ordering on the same consent logic.

How do you track card-linked enrollment correctly?

This is the section that separates an accurate Thanx setup from a misleading one. Card-linked enrollment has two traps, and both have clean fixes.

The first trap is timing. Because enrollment completes at payment, the sign_up event has to fire from your transaction-complete handler, the same callback where you confirm the order succeeded. Firing on a “join now” button counts guests who started but never paid, inflating enrollment.

The second trap is auto-enrollment. Thanx can enroll a large share of digital purchasers automatically at checkout, which means a sign_up could fire on every single order if you are not careful. The fix is the isFirstPurchase guard in the code above: pass true only on a guest’s first qualifying purchase, which your backend or Thanx response can tell you. That way enrollment fires once per member, and every order after that is counted as a purchase, not a new sign-up.

How do you measure Thanx member lifetime value?

Thanx exists to grow customer lifetime value, so your tracking should prove whether it is working. The mechanism is the same as any loyalty program: set the GA4 user_id to the non-PII Thanx member ID and attach a loyalty_member user property to member sessions. Once user_id is set, GA4 stitches a member’s activity across devices into one identity, and you can build a members-versus-non-members comparison.

Combined with the purchase events from your ordering setup, this answers the question that justifies the Thanx investment: do Thanx members spend more per order and visit more often than non-members? Because Thanx captures purchase data through card linking, the member side of that comparison is unusually complete, which makes the LTV analysis more reliable than it would be with a check-in program that misses offline visits.

How do you build a member versus non-member dashboard in Looker Studio?

Once the events flow and user_id is set, Looker Studio turns the data into the comparison that justifies the loyalty spend. The whole dashboard hinges on one dimension: loyalty_member, the user property you registered as a custom dimension in GA4. Break any metric by that dimension and you can see members and non-members side by side.

The setup

Connect Looker Studio to your GA4 property as the data source. Confirm that loyalty_member, loyalty_tier, and loyalty_program show up as available dimensions. If they do not, they were never registered as custom dimensions in GA4, so go back and register them first. Then build three things: scorecards, a comparison table, and a tier breakdown.

For purchase frequency, add a calculated field that divides Purchases by Total users, which gives you orders per guest for each segment. For average order value, use Average purchase revenue or divide Total revenue by Purchases. Lay members and non-members next to each other and the gap in order value and frequency is the number that tells you whether the loyalty program is actually changing behavior.

How do you calculate true member lifetime value in BigQuery?

GA4’s interface tops out at session-level comparison. For real lifetime value, the revenue a member generates across their entire history, you need the GA4 BigQuery export, which is free on the standard daily tier. Enable it under GA4 Admin, then BigQuery links, and after a day of data the query below gives you member versus non-member lifetime value directly.

-- Member vs non-member lifetime value from the GA4 BigQuery export.
-- Replace your_project.analytics_XXXXXX with your dataset, and set the dates.

WITH purchases AS (
  SELECT
    user_pseudo_id,
    user_id,
    (SELECT value.string_value
       FROM UNNEST(user_properties)
       WHERE key = 'loyalty_member') AS loyalty_member,
    IFNULL(ecommerce.purchase_revenue, 0) AS revenue
  FROM `your_project.analytics_XXXXXX.events_*`
  WHERE event_name = 'purchase'
    AND _TABLE_SUFFIX BETWEEN '20260101' AND '20261231'
),

per_guest AS (
  SELECT
    COALESCE(user_id, user_pseudo_id) AS guest,
    MAX(loyalty_member) AS loyalty_member,
    COUNT(*) AS orders,
    SUM(revenue) AS lifetime_revenue
  FROM purchases
  GROUP BY guest
)

SELECT
  CASE WHEN loyalty_member = 'true' THEN 'Member' ELSE 'Non-member' END AS segment,
  COUNT(*) AS guests,
  ROUND(AVG(lifetime_revenue), 2) AS avg_lifetime_value,
  ROUND(AVG(orders), 2) AS avg_orders_per_guest,
  ROUND(SAFE_DIVIDE(SUM(lifetime_revenue), SUM(orders)), 2) AS avg_order_value
FROM per_guest
GROUP BY segment;

The query pulls every purchase, reads each guest’s loyalty_member status from the user properties, and rolls revenue up per guest using user_id where it exists and the pseudonymous ID otherwise. The final step splits guests into members and non-members and reports average lifetime value, orders per guest, and average order value for each. That is the definitive answer to whether Thanx members are worth more, calculated across full history rather than a single session window, and it is the number worth putting in front of an owner deciding whether the loyalty investment pays off.

How do you handle server-side Thanx events?

The practical split: enrollment confirmed in the browser, online redemptions, and app sign-ins go client-side with the dataLayer code above. In-store redemptions, rewards unlocked from offline visits, and card-tokenized purchase confirmations go server-side. Most Thanx restaurants need both halves, and they feed the same GA4 events without conflict.

Thanx event code generator

How do you validate Thanx tracking is working?

What are the most common Thanx tracking mistakes?

Firing enrollment on a button instead of the transaction callback is the headline error, because card-linked enrollment completes at payment. It inflates sign-ups and never reconciles with Thanx.

Firing enrollment on every order is the second error, caused by auto-enrollment. Without a first-purchase guard, every member order looks like a new sign-up. Gate the event so it fires once per member.

Using a card number, phone, or email as the member ID is the dangerous error, because it puts PII into GA4 and risks your data. Use the tokenized or internal Thanx member ID.

Tracking only client-side is the incomplete error, because card-tokenized purchases and in-store redemptions happen without a browser. Capture those with the Measurement Protocol or server-side GTM.

Skipping user_id is the costly error, because without it you cannot prove Thanx members are worth more than non-members, which is the entire reason the platform exists.

Why choose Hustle Marketers for Thanx tracking?

We implement Thanx loyalty tracking the way the platform actually behaves: enrollment fired at payment with a first-purchase guard, rewards mapped to GA4 recommended events, card-tokenized purchases captured server-side, and member identity tied to user_id so lifetime value is provable. Most setups fire a sign-up on a button and call it done. We instrument the whole card-linked model so your loyalty data reconciles with Thanx and your reporting answers real questions, all without disturbing the Olo tracking you already rely on.

Hustle Marketers is a Google Partner, Meta Business Partner, and Microsoft Advertising Partner, with a Clutch-verified 5.0 rating and six Clutch Global Awards in Spring 2026. We hold Upwork Top Rated Plus status with a 99% Job Success Score across 591+ reviews, and our team has driven measurable results across 2,500+ brands and more than $780M in trackable client revenue. If your Thanx numbers do not match GA4, or members and non-members look identical because nothing ties them together, request a free analytics audit and we will map exactly what is firing wrong and what it is costing you.

Frequently asked questions about Thanx loyalty tracking