Cookieless analytics

Sessions are merged via a pseudonymous daily identifier — a hash of the IP address and a random value (salt) generated anew each day and deleted once the day is over; after that, no attribution to the IP address is possible. So there is no browser cookie, no identifier in the browser and no cross-site visitor profile, but still proper session aggregation. Consequence for the figures: visitors are counted per day. Someone who comes on several days of a period counts once on each of those days; new and returning visitors cannot be told apart across the day boundary.

Country, region and city from IP-to-geo mapping (DB-IP, EU-hosted, privacy-compliant). Browser family and OS from the User-Agent; device class additionally from consent-free client hints (Sec-CH-UA) and the viewport width, because since version 134 Chrome reports every Android device identically in the User-Agent while the client hints state the form factor directly. All coarse signals, no fingerprinting, no IP retention after hashing.

The tracker records two metrics: full monitor size (screen.width / height) and the actual browser window (window.innerWidth / innerHeight). Both are aggregated as separate cards in the analytics dashboard — so you can tell whether users on a 27″ monitor are rendering your page in a 900×900 window side-by-side with another tool, which is key for responsive design.

Instead of typing pixel values you filter by nine ready-made classes: ultrawide (21:9 and wider), widescreen (16:10 to 21:9), classic (4:3 to 16:10), portrait, plus the width tiers UHD/4K (3840 px+), WQHD (2560-3839 px), Full HD (1920-2559 px), HD (1280-1919 px) and small (below 1280 px). Sessions that reported no screen size drop out of the result rather than being counted in some classes and not in others.

Fourteen filters accept several values at once: country, continent, city, device, browser, operating system, channel, page language, visitor language, hostname, provider, traffic type, event, resolution and screen class. Several values inside one filter are combined with OR, different filters with AND - so Full HD together with WQHD, but only from Germany and Austria, is a single query. Save the combination as a segment and the full list of values is kept, ready to be applied as a lens across every report with one click.

Direct, organic search, paid search, social, referral, email — automatically classified. UTM parameters (utm_source, _medium, _campaign, _term, _content) parsed and grouped. Per campaign: visits, conversions, revenue.

Goals defined via URL match (e.g. /thank-you) or JavaScript event. Conversion funnels visualisable up to 8 steps. Revenue tracking via xictraq.revenue() for e-commerce.

The tracker captures cart, checkout funnel and orders automatically. WooCommerce, Shopify, Shopware 5/6, Magento, PrestaShop, OpenCart, OXID, JTL-Shop, Gambio, plentymarkets, Ecwid, BigCommerce, Squarespace, Wix, VTEX, SFCC, Snipcart and 10+ more are usually detected without code. It reads the order amount on WooCommerce, Shopify, Shopware, PrestaShop, JTL-Shop, Ecwid, Snipcart and from a purchase event in the dataLayer; on the other systems the order counts without an amount. Automatic detection does not capture coupon code, discount or refunds, and captures tax and shipping costs only in the cart snapshot, not on the order itself: pass coupons with xictraq.revenue(amount, currency, orderId, extras) using the fields coupon, discount, tax and shipping in extras, and refunds with xictraq.refund(). If a Shopware 6 shop is connected with the order import, the import itself records fully refunded orders as refunds. For custom shops: xictraq.cart(), xictraq.checkout(), xictraq.revenue(), xictraq.refund() JS API.

With xictraq.identify(userId, traits) you link browser sessions to your CRM or shop account. In Shopware, Shopify, WooCommerce/WordPress, PrestaShop, Drupal, Joomla, TYPO3 and BigCommerce this happens automatically — logged-in customers are detected. The customer number and type or group are stored, plus name or company where the shop provides them. This is personal data: mention the linking in your privacy policy.

Beyond lab data (Lighthouse), the tracker also collects field data directly from your visitors' browsers. Segmentable by device, browser, geo. Shows p75 (Google threshold) and average values.

User-Agent-based detection of known bots/crawlers plus behavioural heuristics (pageviews with zero dwell time and no interaction, hits from datacenter/bot networks, single hits without scroll or engagement). Detected bot and datacenter/VPN access is flagged and excluded from human metrics, but reported separately in the network cards.

A transition graph between your most-visited pages: from the consecutive pageviews of each session, XICTRAQ computes the top entry and exit pages plus the most frequent page-to-page transitions. So you see where visitors drop off going from landing → product → checkout. The flow is filterable by entry page.

A global comparison control in the overview (“Compare with: previous period, previous year or custom from–to”) affects every card at once. KPI cards show the delta to the comparison period, breakdown cards a comparison pill in the header. Colouring is direction-aware: more visitors or conversions = green, higher bounce or error rate = red. Backend parameter compare_mode=previous|year|custom.

Every dashboard and analytics card shows meaningfully different content per grid size (1×1 to 4×4): more height means more rows and depth, more width more columns. In each card's gear menu you pick size presets with a live preview — the content adapts instantly.

Table cards such as “Your websites”, alarms, ROAS, heartbeat schedule, uptime log, API keys/endpoints, DNS records or broken links are sortable by column click; individual columns can be shown or hidden. The selection is saved per card and persists across sessions.

A card shows the distribution of pages per session across five buckets (1, 2, 3–5, 6–10, 11+), each as count and percentage — so you see at a glance how many visitors click on beyond the landing page and how deep they go into your site.

In single-website mode you place event markers directly on the trend chart (e.g. relaunch, campaign start, price change). This lets you attribute traffic spikes to a concrete event at a glance.

The default tracker loads t.js from api.xictraq.com — adblockers can block that domain. Optionally configure nginx reverse proxies on your own domain to api.xictraq.com: /t.js for the tracker, /a/ for data collection and — once you use session recording — /rx.js for the recording library. Tracker, pageview beacons AND the pixel fallback then route via your own host, and content blockers usually can no longer tell them apart from your own requests — no separate config for the pixel is needed, it goes through the same /a/ proxy. The /rx.js rule is only required when recording is active: otherwise a strict Content-Security-Policy (script-src 'self') would block the recording library loaded same-origin. Important: embed the pixel as /a/px (extensionless), NOT /a/p.gif — the .gif extension would be intercepted by static image serving before the proxy (404).

Per channel you get the number of clicks and the number of sessions they came from — 40 clicks from 3 sessions mean something different from 40 from 38. Below that the card lists up to twelve targets with their full address, so it becomes visible which phone number or mailbox is actually in demand. Outbound clicks on ordinary external links are counted separately and never as a lead.

Classification happens at query time from the stored target address, not at capture time. If you have been running the tracker for months, contact conversions therefore appear across your entire history — no new snippet, no data migration.

The tracker detects the shop system itself and wires up the e-commerce events automatically — you only embed the snippet, no extra code. Supported are e.g. WooCommerce, Shopify, Shopware 5/6, Magento/Adobe Commerce, PrestaShop, OpenCart, OXID, JTL, Gambio, BigCommerce, Squarespace, Wix, nopCommerce, CS-Cart, VTEX, Salesforce Commerce Cloud (SFRA), SAP Commerce/Spartacus, Shoptet, plentymarkets, Volusion/Shift4Shop, Zen/osCommerce, X-Cart, Snipcart, Ecwid and modified/xt:Commerce. Captured are the typical steps of the purchase journey: product view, add to cart, remove from cart, checkout and purchase. Refunds and coupon codes are reported by the shop via xictraq.refund() and the coupon field of xictraq.revenue(). Removing items and changing quantities is detected both on the cart page and in the offcanvas/mini-cart (e.g. Shopware 6); the order number is read from the finish page.

Every e-commerce event carries the product-related fields: product name, article number/SKU, the chosen variant (e.g. size or colour), unit price, quantity, category and manufacturer/brand. Category and manufacturer are read automatically from structured data and page markup: JSON-LD (schema.org Product/BreadcrumbList), microdata and meta tags (itemprop=brand, product:brand) plus the breadcrumb path — with shop-specific additions for Shopware 6 and other systems. This lets you break analyses down to variant, category and manufacturer level instead of just the parent product.

At checkout and purchase the tracker captures the cart in full: all line items with name, variant, article number, quantity plus unit and line price, together with subtotal, shipping, tax and grand total. These values are always reported both net and gross — regardless of whether the shop displays its prices net or gross. Tax mode and currency are carried along as well, so the figures stay comparable across different shops.

The tracker detects when visitors look at product images more closely: opening a lightbox or zoom and switching between gallery images are captured as events — each with image URL, alt text and title. In the session timeline the viewed image is shown as a small thumbnail (proxied via XICTRAQ). So you see which product views actually attract attention before an item is added to the cart.

Real-user monitoring straight from your visitors' browsers, millisecond-accurate and without cookies: TTFB (server response time), FCP (first visible element), LCP (largest contentful element), INP (interaction responsiveness), CLS (layout stability) and the full page load. Unlike pure lab measurements (Lighthouse), this field data shows the performance actually experienced — segmentable by device, browser and geo.

When a customer is logged into your shop, the tracker can link the session to the account — automatically in e.g. Shopware, Shopify, WooCommerce/WordPress, PrestaShop, Drupal, Joomla, TYPO3 and BigCommerce. Captured are the customer number, the type (B2B or B2C) and — if your shop exposes them in the DOM or in profile/checkout form fields — name and company. There is no forced PII collection: only what your shop already displays is transmitted. For other systems a generic convention applies: window.xictraqUser, a meta[name="xictraq:user-id"] tag or a data-user-id attribute — alternatively the manual call xictraq.identify(userId, traits). Identified customers appear in a dedicated “Identified users” view, are linked across days and are shown directly as the matched customer in the visitor detail.

All capabilities listed come via a single script tag. The file name rotates per content hash and is served with a Subresource Integrity (SRI) signature, so the browser enforces unchanged code. For visitors without JavaScript a noscript pixel ensures the pageview is still counted.

The entry view shows the core figures for the selected period: revenue, orders, average order value, conversion rate and the abandonment rate. So you keep an eye on the shop trend before diving into the individual tabs.

A chronological list of all carts and orders with status: open, abandoned, purchased or refunded. Each entry expands to show the contained line items, totals and — where available — the order number from the finish page. So you see the actual purchase journey instead of only aggregated numbers. If a Shopware 6 shop is connected through the shop API and the order status is switched on, each order additionally shows the state of order, payment and delivery from the shop.

Optionally, XICTRAQ uses the Admin API of a connected Shopware 6 shop to fetch the entire existing order history and then, on an ongoing basis, new and changed orders, including those created in the Shopware Administration, for example after an order by telephone. You switch the import on in the website settings under shop API; like the other e-commerce reports it is available from the Business plan. If a purchase captured by the tracker exists for an order, the import adds to that purchase instead of counting it twice. Online orders without a captured purchase are taken over two hours after the order at the earliest, orders from the Administration with the next fetch; cancelled orders do not count. Imported orders count in revenue, orders, order value, buyers, products, finances, payment and shipping methods and in the order history, where they are marked as imported. They stay out of conversion rate, funnel and ROAS because no visit underlies them; among the revenue sources they appear as a separate entry “No visit (shop)”. Fetched are the order number, time, amounts with tax and shipping costs, currency, payment and shipping method, states and line items, as well as the name, company and customer number of the person ordering, but no email address, no address, no telephone number, no comment of the person ordering and no VAT ID. XICTRAQ stores name, company and customer number only for orders from the last 365 days and removes them afterwards; the order itself still counts without these details. Share links show no customer data, neither from the import nor tracker identities. If you switch the import off or disconnect the shop, XICTRAQ deletes the imported data.

With the import switched on, the data from Shopware also feeds into the purchases captured by the tracker. If a tracker purchase lacks the payment or shipping method, XICTRAQ takes the value of the matched order from the shop, in the “Payment and shipping methods” report, in the order history and in the export. Line items of a matched order come from the shop, with exact quantity, article number and variant and without discount lines; the tracker's cart snapshot only applies where the shop data is missing. This covers the product list, categories, bestsellers and the order export. The order history can additionally be filtered by origin (tracker, import, created in the shop admin) and by the state of order, payment and delivery in Shopware; the counters next to the filters cover the whole period. If a tracker identity carries the same customer number as a customer from the import, the customer list and the identified users show both as one customer with summed orders and revenue. A website that only imports orders and has no page view yet opens the e-commerce area in analytics instead of only the tracking script instructions.

By default a purchase captured by the tracker counts even if the order is cancelled in the shop later; the figures stay as the tracker measured them. Such purchases carry the flag “Cancelled in shop” in the order history, in the latest orders and in a visitor’s timeline, and the “Cancelled in shop” tile in the order history counts them for the period. The “Cancellations: without” switch in the e-commerce tab leaves them out of revenue, orders and the other figures together with a refund for the same order, and so does the setting “Exclude cancellations” on the revenue and order cards of the dashboard; funnel and abandonment rate stay. A purchase counts as cancelled when the order the import matched to it has the order state cancelled, without a matched order by the state from the order status fetch; without either XICTRAQ knows of no cancellations.

A share link shows figures such as orders and revenue, but never customer data: neither name, company and customer number from the shop import nor tracker identities with name, company or customer ID. This applies to the order history, orders, customer list, identified users, timeline and visitor profile as well as to downloads from the share.

Per product, views, add-to-cart actions and generated revenue are compared. So you see which items are seen a lot but rarely bought — and which convert reliably. Thanks to variant and SKU fields the analysis can be broken down to the variant level.

The cart tab lists the most recently captured carts with content and value. The abandonment tab reports the abandonment rate and the lost cart value — i.e. the revenue that stalled in the checkout funnel. This makes it visible where purchase intent is lost.

The recovery tab brings together identified customers with an open cart — i.e. sessions linked to an account via the auto-identify connection that left an uncompleted purchase. This forms the basis to follow up in a targeted way, provided you have a legal basis for it.

The finance tab transparently works through the path from gross via discount, net, shipping and tax down to refunds. Revenue sources attribute turnover to channels and campaigns, the customer tab to identified accounts. So you can trace where revenue comes from and how it is composed.

In the e-commerce area you invoke the AI assistant with prepared analyses: funnel, abandonment, products, finances and recovery. The assistant reads the selected period and scope and phrases the findings in plain language, without you having to type your own question.

When support accesses an account via impersonation, it runs as a separate admin session. These sessions appear only in the admin area and do not show up in the customer's session list — keeping the customer's device overview free of support access.

The account digest is enabled by default and can be turned off per account under Settings → Profile. The text is generated from fixed rules by default (no token usage); a richer AI narration is prepared on the platform side but currently not switched on. Only site names and aggregated finding severities are processed.