Basic mechanics

Dema tracks three default events on your site:

  • Page views
  • Product views
  • Orders

To associate these events with a user, we rely on the dv_track cookie, which establishes (and maintains) a session for each visitor. A session ends after 30 minutes of inactivity, mirroring Google Analytics Universal’s approach.

Session logic: Just like GA Universal, if a user is inactive for more than 30 minutes, any new activity starts a new session.


Where is the script implemented?

Dema offers multiple methods to deploy tracking, depending on your platform:

SPA support: For single-page applications, you must manually fire Dema events on navigation or route change. Refer to our SPA tracking guide for detailed instructions.


How sessions work in Dema

In Dema, a session represents a group of user interactions that occur within a given time frame. Sessions allow us to connect actions like product views and orders to the same user, providing a comprehensive view of their journey on your site.

When a session starts

A session begins when:

  • A user visits your website for the first time, creating a new dv_track cookie.
  • A user returns to your website after the previous session has ended (e.g., after being inactive for more than 30 minutes).
  • A user lands on your website via a new marketing campaign. For example:
    • If a user clicks on a paid ad (e.g., Google Ads or Meta campaign) with different UTM parameters than their previous visit, a new session begins.
    • If a user navigates organically (e.g., through bookmarks or direct links) without updated campaign parameters, it continues the previous session (if within the 30-minute window).

When a session ends

A session ends when:

  • Inactivity timeout: There is no interaction for 30 minutes. For example, if a user browses your site and leaves, their session will close automatically after 30 minutes of inactivity.
  • Campaign source changes: If a user arrives on your site via a new marketing campaign (e.g., updated UTM parameters), a new session begins, even if the 30-minute inactivity window has not been reached.
  • Daily reset: Sessions reset at midnight to simplify daily reporting.

Why sessions matter

By grouping interactions into sessions, Dema enables you to:

  • Attribute actions like orders or product views to specific marketing campaigns.
  • Calculate metrics like session duration and average order value.
  • Identify behavioral patterns, such as abandoned carts or repeat visits.

Dema’s session logic mirrors Google Analytics Universal to provide familiar and actionable insights for your business.


Referral and UTM mapping logic

Dema categorizes referral traffic using a predefined list of referral sources. These sources are grouped into channel groups and channels, helping merchants understand where their traffic originates.

How referrals are categorized

When a user lands on your site via a referrer URL, Dema matches the domain against our predefined referral mapping. Each domain is categorized into one of several traffic channel groups:

  • Organic: Search engines like Google, Bing, and DuckDuckGo.
  • Social Organic: Social platforms like Facebook, Instagram, and Twitter when no ad parameters (e.g., UTM) are present.
  • Display: Ad networks or display ad providers like Google Display Network or Adform.
  • Affiliate: Traffic from affiliate marketing platforms such as Tradedoubler or Webgains.
  • Retargeting: Traffic from retargeting platforms like Criteo.
  • Price Comparison: Sources like PriceSpy or Kelkoo.
  • Email: Traffic originating from email providers such as Gmail or Yahoo Mail.
  • Referral: Generic referrals from forums, niche sites, or other uncategorized domains.

Default behavior: If a referral source does not match any predefined channel groups or channels, it defaults to “Referral” unless UTM parameters override it.

UTM overrides referral traffic

If UTM parameters are present in the landing URL, they take precedence over the referral logic. Merchants can map UTM parameters (e.g., utm_source=meta, utm_medium=cpc) to specific channel groups or channels within Dema. For example:

  • utm_source=facebook and utm_medium=cpc can be mapped to “Meta – Paid Social”.
  • utm_source=google and utm_medium=organic can be mapped to “Google Organic”.

This mapping system allows merchants to define custom attribution rules that better align with their business model.

Session resets: When UTM parameters override a referral source, Dema starts a new session to ensure accurate campaign attribution. This behavior may result in more sessions being reported compared to systems with different attribution models.

Predefined referral mappings

Dema uses a comprehensive list of referral domains and their associated regex patterns to categorize traffic. Below are some examples:

Organic traffic

  • Google: ((www|cse|images|encrypted)\.)?google\.[a-z]+
  • Bing: ([a-z-]+\.)?bing\.com
  • DuckDuckGo: ([a-z-]+\.)?duckduckgo\.com

Social organic traffic

  • Facebook: ([a-z-]+\.)?facebook\.com
  • Instagram: ((www|l)\.)?instagram\.com
  • TikTok: ([a-z-]+\.)?tiktok\.com

Display traffic

  • Google Display Network: (dp|googleads|adclick|securepubads)\.g\.doubleclick\.net
  • Adform: track\.adform\.net

Affiliate traffic

  • Tradedoubler: ((clk[a-z]{2,4})?|pdt|www)\.tradedoubler\.com
  • Adrecord: ((graphics|click|www)\.)?adrecord\.com

Why referrals matter

By categorizing referral traffic and enabling UTM overrides, Dema provides merchants with:

  1. Clearer attribution: Distinguish between organic and paid sources, even when they originate from the same domain.
  2. Customizable mapping: Align traffic sources with your marketing strategy using the UTM mapping system.
  3. Accurate reporting: Ensure every session is attributed to the right channel, improving ROAS and profitability analysis.

Dema’s referral logic is designed to adapt to your business needs while maintaining accurate attribution across all traffic sources.


Internal traffic and channel consistency

In Dema, internal traffic refers to interactions originating from your own domains or trusted services, such as payment processors or checkout platforms. Handling internal traffic correctly is crucial to maintain accurate attribution and session continuity.

How internal traffic is classified

Dema uses a global list of predefined regex patterns to detect internal traffic. These patterns are designed to recognize domains commonly associated with payment gateways, banking systems, and other trusted internal services. If a referrer matches one of these patterns, the session is classified as direct/direct traffic. This ensures that:

  • Payment redirections or checkout steps do not split sessions.
  • Attribution is preserved for the original marketing channel.

Custom internal traffic rules for merchants

Merchants can extend or override the global internal traffic rules by adding custom regex patterns. This is particularly useful for businesses using unique payment providers or internal tools that redirect users.

Prioritization of internal traffic

Internal traffic rules take precedence over other referrer or UTM mappings. For example:

  • If a referrer matches both an internal pattern and an external channel (e.g., organic), Dema classifies the session as internal.
  • This prevents redirections from payment processors or similar services from incorrectly attributing the session to another channel.

By ensuring internal traffic is categorized as direct/direct, Dema avoids inflated session counts and preserves accurate attribution for external campaigns.


GA Universal vs. GA4 vs. Dema: Why numbers differ

Analytics platforms often report discrepancies in sessions and events due to differences in definitions, tracking methods, and technical configurations. Below are some reasons you may see variations:

Differences in session logic

  • Dema:
    Sessions are based on a 30-minute inactivity window. For example, if a user leaves your site and returns after 29 minutes, the activity counts as the same session. If they return after 31 minutes, it counts as a new session. Sessions also reset at midnight and when UTM parameters change (e.g., switching campaigns).

  • GA4:
    GA4 uses an event-driven model, which focuses less on traditional session boundaries. It does not reset sessions at midnight or when UTM parameters change, resulting in different amount of sessions reported compared to GA Universal or Dema.

Tracking configurations

  • Bot filtering:
    GA4 applies bot filtering, which may affect number of session counts differently to Dema’s bot filtering. If bots are not filtered as aggressively in other systems, session counts could appear higher.

  • Ad blockers and privacy settings:
    Both Dema and GA4 can be affected by ad blockers or privacy tools, but GA4’s event-driven tracking may recover more interactions using first-party cookies, resulting in more accurate numbers.

  • Triggering logic:
    Dema uses explicit event triggers for pageviews, product views, and orders. GA4 may include automatically captured events or inferred actions, which can inflate the number of reported events and sessions.

Technical nuances and implementation

  • Cross-domain tracking:
    Differences in how cookies persist across domains can lead to sessions being split (or not). GA4’s configuration for cross-domain tracking is different to Dema and GA Universal, potentially reducing inflated session counts.

  • Timeout settings:
    In Dema, session timeout mirrors GA Universal’s 30-minute window. GA4 allows configurable timeout windows (up to 7 hours), which can significantly impact session counts depending on user behavior.

  • Handling of UTM resets:
    Dema resets sessions when UTM parameters change to ensure accurate attribution for each campaign. GA4 does not always enforce session resets on campaign switches, leading to fewer but longer sessions.

Additional reasons for discrepancies

  • Event mapping:
    Dema maps events explicitly (e.g., page views, product views, orders), while GA4’s model focuses on custom events with parameters. This can make GA4’s event totals appear higher or lower depending on the configuration.

  • Session deduplication:
    Dema processes data in real-time and merges updates for the same session (e.g., from webhooks and tracking scripts), minimizing duplication. GA4 may treat similar scenarios differently, potentially leading to discrepancies.

  • Backfilled orders:
    Dema fetches missing orders directly from your ecommerce platform and associates them with the correct session. GA4 may not handle backfilled data in the same way, leading to discrepancies in reported conversions.

Platform-specific logic

  • Referral traffic categorization:
    Dema’s robust referral logic explicitly maps referrer domains into predefined categories, whereas GA4 relies on its default algorithms, which may categorize referral traffic differently or ignore some referrers.

  • Internal traffic handling:
    Dema has a built-in internal traffic whitelist (e.g., for payment providers and checkout domains) to ensure these interactions are classified as direct/direct traffic. GA4 might misattribute internal traffic as external, resulting in inflated session counts.

  • Customizability:
    Dema provides merchants with full control over mapping UTM parameters and referral logic. GA4 applies predefined logic for most attributions, which may not align with your specific business needs.

Key takeaway: Discrepancies don’t mean errors. They reflect differences in methodology, offering distinct perspectives on user behavior. Dema’s logic prioritizes real-time updates, session accuracy, and backfilled data to ensure a complete view of your ecommerce performance.


Data privacy & compliance

  • GDPR/CCPA compliance: Dema does not enforce consent automatically. It is the merchant’s responsibility to load the script only after obtaining user consent.
  • Cookie usage: The dv_track cookie stores only an anonymous session ID and no personal data.
  • Regional considerations: Subdomains and cross-domain tracking are supported as long as the same cookie policy is applied across domains.

Verifying your tracking integration

To confirm that Dema is correctly capturing data:

  1. Open the Network tab in your browser’s developer tools.
  2. Navigate to a tracked page or trigger an event (e.g., a product view or order).
  3. Look for requests sent to Dema’s endpoint (https://tracker.dema.ai) and ensure they include relevant parameters like eventType, url, and timestamp.
  4. Check your Dema dashboard for real-time updates to confirm data is being processed.

If you don’t see data in Dema, ensure the script or tag is firing, and check for network issues (e.g., ad blockers or privacy settings blocking requests).


Troubleshooting common issues

Missing events or no data in the dashboard

  • Verify script loading: Use browser developer tools to confirm the tracking script is loading. Look for requests sent to Dema’s endpoint.
  • Check triggers in GTM: Ensure triggers are configured correctly and firing under expected conditions.
  • Ad blockers: Confirm that ad blockers or privacy settings aren’t preventing the script from executing.

Duplicate or inflated session counts

  • Multiple scripts: Ensure the Dema script isn’t implemented in multiple locations (e.g., GTM and directly in the code).
  • Duplicate tags in GTM: Review your GTM container to confirm tags aren’t firing redundantly.

Discrepancies compared to GA4 or Shopify

  • Backfilled orders: Dema fetches orders directly from your ecommerce platform, which may result in more complete data compared to GA4 or Shopify analytics.
  • Different session models: GA4’s event-based sessions differ from Dema’s session-based logic, which mirrors GA Universal.

SPA (Single-Page Application) tracking issues

  • Navigation changes not tracked: Single-page applications (SPAs) do not trigger traditional page reloads, which can cause the Dema script to miss critical events.
    • Solution: Ensure that Dema’s tracking script is manually fired on route changes using our SPA tracking guide.
    • Impact: Missed pageviews and sessions if events are not triggered correctly.
  • Wrong consent triggering: The Dema script may be implemented in a way that does not align with user consent settings (e.g., firing before GDPR/CCPA consent is obtained).
    • Solution: Confirm that the script is only loaded after consent has been granted. Most platforms, like GTM or Shopify, allow conditional firing based on consent.
    • Impact: Non-compliance with GDPR/CCPA regulations or inaccurate data due to improperly tracked sessions.

Tracking configuration mismatches

  • Inconsistent UTM parameters: If UTM parameters are not consistently applied across platforms (e.g., missing on ad links), sessions may not align properly.

    • Solution: Regularly audit your campaign links to ensure UTM parameters are correctly structured and mapped in Dema.
  • Improper cross-domain tracking: Inaccurate cookie persistence across subdomains or separate domains can lead to session splits or misattribution.

    • Solution: Use a consistent domain policy and configure cross-domain tracking in Dema to unify sessions across all domains.

Other potential issues

  • Event deduplication: If custom event triggers are misconfigured (e.g., firing on both page load and scroll), you may see inflated event counts.

    • Solution: Audit and refine your custom event configurations to prevent redundant triggers.
  • Delayed data visibility: Network issues or high server load may delay event processing.

    • Solution: Check for delays in the Dema dashboard and ensure the tracking endpoint (https://tracker.dema.ai) is reachable.

Unresolved issues may lead to gaps in data, compliance risks, or inaccurate reporting. Always test your tracking setup thoroughly after changes.