--- title: "Release Notes" description: "Sealmetrics product updates, new reports, API changes, and platform improvements — latest release Shopify Web Pixel tracking for custom-app stores and a fix for the Overview comparison line (October 2026)." canonical_url: "https://docs.sealmetrics.com/changelog" lang: "en" date_generated: "2026-10-08T07:55:18.470Z" source_hash: "b701bec6dd43d3d45d83b35163ad7b490ee23e77691dc6b185209a5f42338bbd" content_type: "documentation" owner: "docs" llm_priority: "useful" source_file: "changelog.mdx" publisher: "Sealmetrics" --- # Release Notes Canonical page: https://docs.sealmetrics.com/changelog --- ## Shopify custom apps now track through Shopify's Web Pixel (October 8, 2026) This applies to Shopify stores connected through a **custom app** (billed through Sealmetrics). Stores on the public Sealmetrics app, which tracks through the theme app embed, are not affected. ### Why Since October 1, 2026 Shopify no longer lets apps create ScriptTags, the mechanism custom-app connections used to load the tracker, so new connections were failing. ### What changed - New custom-app connections install a **Shopify Web Pixel** instead of a ScriptTag. It is activated when the app is installed: no theme edit and no app embed to turn on. - The Web Pixel tracks the same funnel as before — page views, product views, add to cart and checkout start — and, like the Sealmetrics tracker, it uses no cookies. - Purchases are still confirmed server-side by the Shopify order webhook, with the same order data (revenue, currency, items). When an order arrives, it is linked to the visit that started the checkout, so channel and campaign attribution work as before. --- ## Overview comparison line lined up by date (October 8, 2026) With a comparison active, the dashed line on the Overview chart (the comparison period) could be shifted to the right. The chart paired both series by position, but the current period only includes the days — or, in the Today and Yesterday views, the hours — that have traffic, while the comparison covers the whole range. Every day or hour without data in the current period pushed the comparison one slot later. The effect was largest on sites whose data starts partway through the selected range, for example **This year vs Previous year** on a site tracked since March: the comparison line was drawn weeks out of place. Hourly views were affected by any hour without visits. The comparison line is now matched to the current period by date (and hour), so each point sits over the day it belongs to. Your data and the comparison totals were never affected — only where the line was drawn. No action required. One known limit: the chart still starts on the first day with data in the current period, so the part of the comparison period before that date is not drawn. --- ## Free tier on signup and paging for the Funnel API (September 28, 2026) ### Sign up without a credit card Self-service signup no longer goes through Stripe checkout. Create an account, verify your email, then create an organization: it starts on the **free tier**, with **1,000,000 events total** — cumulative for the life of the organization, not reset monthly. Accounts provisioned through the [Agentic Package](/integrations/agentic-package) share the same quota. The 14-day trial of a paid plan is unchanged. See [Is there a free plan?](/billing/faq#is-there-a-free-plan). ### If you use the API - `POST /auth/register` no longer opens a session: `access_token` is empty, `requires_subscription` is `false`, and the session starts when the email is verified. The only exception is a signup resuming an MCP OAuth consent, flagged by the new `session_created` field. See [Registration](/api/authentication#registration). - `GET /stats/funnel` takes a new `page` parameter and returns `page`, `limit` and `truncated`, so you can page through every UTM combination of a period. `limit` goes up to 10,000. - Large funnel requests (`limit` above 100, or any page after the first) run one at a time per site and three at a time overall. Over either cap the API answers `429` with `Retry-After: 10`; a request that runs too long answers `422`. See [Paging large funnels](/api/stats#paging-large-funnels). --- ## Report fixes — filters, comparisons, exports and device detection (September 22, 2026) An audit of every report found places where the dashboard showed numbers that did not match what you had selected. This release fixes them. Your stored data was never affected: the problems were in how filters and comparisons were applied when reading it. ### Filters and comparisons - **Evolution and Overview now apply Source, Medium and Campaign filters.** Before, they were ignored and the chart showed site-wide totals. - **Comparison selector.** **No comparison** no longer compares, **Previous year** compares with the same period last year, and **Custom comparison** works: pick a start date and the comparison covers a period of the same length. The choice survives page reloads. - **Overview comparison line** uses the same filters as the current period. - **Conversions cards** show the change against the comparison period. - **Funnel by UTM** counts conversions for each `utm_term`. Before, each term showed its campaign's total. - **Properties → Rates** is calculated on entrances. - The AND/OR selector is gone from Pages, Sources and Funnel, where only AND was applied. A notice appears when a filter value contains a comma and cannot be applied. ### Reports and exports - **Evolution**: weeks (ISO, starting Monday) and months no longer shift by one day for users west of UTC. The hourly export has one row per hour with an `Hour` column. - **Pages** grouped by URL also adds up the comparison period. - **Funnel** drop-off labels sit under the right step. - **Geography** sorts by country name, not by country code. - **Exports** show revenue in your site's currency instead of `$`. ### Browser and device detection (from September 22 onwards) Classification is more accurate. Past data is not reclassified, so expect a step change in browser and device reports from this date: - Samsung Internet and Opera are no longer counted as Chrome. Chrome, Firefox and Edge on iPhone are no longer counted as Safari. Facebook and Instagram in-app browsers appear under their own names. - Android tablets are counted as tablets, including in "desktop site" mode, and Chromebooks appear as ChromeOS. - Fewer Android tablet visits are flagged as suspicious traffic. - Known limits: Brave is reported as Chrome, an iPad in desktop mode as desktop/macOS, and Android TVs as desktop. ### If you use the API - `contains`, `not_contains` and regex filters on `/stats/sources` (and related endpoints), `/stats/funnel` and `/stats/channels` are now **case-insensitive**, so they may return more rows. `eq` and `in` stay exact. - New `compare=custom` with `compare_start_date`. The end date follows from the length of the current range; `compare_end_date` is rejected with a `422`. - `/stats/properties/breakdown` returns `entrances` for each row. The MCP server's tools are unchanged: their filters match exact values, and comparisons remain `previous` and `yoy`. --- ## Country and landing-page filters — errors instead of unfiltered numbers (September 21, 2026) A filter that could not be applied used to be dropped without warning, and the numbers came back **unfiltered**. That happened in three ways. A country name such as `Spain` passed as `country` was ignored by some API endpoints and caused a `500` on others. The MCP server also discarded any argument a tool did not declare, so an AI assistant could pass `country` to `get_overview` and present site-wide totals as if they were filtered. Filters that cannot be applied are now rejected with an explicit error. ### What changed - **`country` takes a code, never a name.** Every endpoint and MCP tool that filters by country accepts an ISO-3166-1 alpha-2 code (`ES`, `US`, case-insensitive) or `Unknown`. Anything else returns a `422` from the API that names the parameter. The MCP server rejects it before calling the API and points to `get_countries`, which lists the codes that have traffic. - **`Unknown` is filterable.** The country comes from the browser's timezone. When that timezone maps to no country, the visit is stored as `Unknown`, and `country=Unknown` now isolates that traffic. - **MCP tools reject arguments they do not support.** Instead of dropping them silently, a tool answers `Unknown argument "" for . Accepted: …` and does not query the API. - **New `country` filter** on the MCP tools `get_overview`, `get_microconversions`, `get_campaigns`, `get_devices`, `get_traffic_mediums` and `get_traffic_sources`, and on `GET /stats/overview` in the API. - **New `landing_page` filter** on `get_top_sources` / `GET /stats/sources/top` and on the three raw tools and endpoints (conversions, microconversions, conversion items). On `get_top_sources` it returns the sources of the sessions that entered on that page, so the totals add up to that page's entrances, not the whole site's. ### If you automate on the responses - `get_top_sources` / `/stats/sources/top` **with** `landing_page` reads the landing-page report, which has no pageview data. Those rows have **no `page_views` field**; every other metric is present. Without `landing_page`, the response is unchanged. - A request that used to "work" with a country name now fails with a `422`. Treat that as a signal that its earlier results were not filtered. ### Action required - **Hosted connector** (`https://mcp.sealmetrics.com/mcp`): already updated, nothing to do. - **Local server** (`@sealmetrics/mcp`): update to **1.10.1** or later. If your config uses `@sealmetrics/mcp@latest`, restart your client. Details: [MCP Server — filters](/integrations/mcp-server#filters-country-and-landing_page) and [API — filtering by country](/api#filtering-by-country). --- ## Privacy documentation corrected — how the session identifier works (September 21, 2026) This is a correction to our documentation, not a product change. Sealmetrics works exactly as it did yesterday, and **no action is required**. We are publishing it here because customers use these pages in security reviews and vendor due diligence. ### What the documentation said Several privacy and compliance pages described the session identifier as a short-lived, in-memory "context marker". They also said Sealmetrics records "only four variables" per hit and uses no fingerprinting. That description was incomplete, and in places it was wrong. ### What actually happens - **In the browser**, the tracker computes a hash of standard device characteristics — user agent, timezone, languages, screen resolution, colour depth, dark-mode and reduced-motion preferences, CPU core count and device memory — together with your site's ID. That hash is a device fingerprint. Nothing is written to the visitor's device: no cookie, no localStorage, no sessionStorage. - **On the server**, before anything is stored, the hash is re-keyed with a server-side secret and a salt that rotates every day. The previous day's salt is destroyed at rotation, so the stored identifier changes daily and two days of the same device cannot be re-linked, not even by Sealmetrics. The hash as sent by the browser is never stored. - **Retention.** The live session lasts 2 hours of inactivity, in memory. The daily identifier is kept in the per-hit log, which is purged after 1 day. Aggregates never contain it. - **Fields per hit.** Besides the timestamp, user agent, page URL and referrer, each hit carries the browser timezone (the source of the country) and the session identifier. Screen size and languages are only used to compute the hash: they are not stored and not reported. ### What we changed - [What We Track](/security-privacy/what-we-track) now describes the session identifier, the fields and their retention accurately, and it is the reference for everything above. - The FAQ, the getting-started pages and the compliance self-assessments now use the same wording. Where a page's ePrivacy reasoning relied on "nothing is read from the device", it now relies on the audience-measurement consent exemption. The self-assessments remain our own assessments; no supervisory authority certifies analytics tools. - One blog post, whose description of how data is aggregated did not match the product, has been unpublished while we review it. We should have described this accurately from the start, and we're sorry to anyone who relied on the earlier wording in a review. If you completed a vendor assessment using the old pages, the updated [What We Track](/security-privacy/what-we-track) page is the one to reference. --- ## UTM Mapping — override the UTM a URL already carries (September 21, 2026) Each UTM mapping now has an option, **Override the UTM if the URL already has one**. It is **off by default**, so every existing mapping keeps working exactly as before. ### Why Until now, a UTM already present in the URL always won over a mapped value. That is the right default when your team tags links, but not when the tagging comes from a platform you can't change. The typical case is a Google Shopping or Performance Max product feed: the product links reach Google with `utm_source`, `utm_medium` and `utm_campaign` already set by the platform, and the Google Ads final URL suffix can only **append** parameters, never remove them. Paid Shopping clicks were attributed to the feed's campaign instead of the real one, with no way for the advertiser to fix it. ### What changed - **New per-mapping option.** Tick **Override the UTM if the URL already has one** when you create a mapping, or flip the **Override** switch on its row in the list. With it on, the mapped value is written even when the URL already carries that UTM. - **Default behaviour unchanged.** Without the option, explicit UTMs still win and the mapping is skipped. - **Ties between mappings.** An overriding mapping also replaces what an earlier mapping wrote on the same UTM; if several overriding mappings target the same UTM, the most recently created one wins. - **Click IDs are out of scope.** `gclid`, `fbclid`, `msclkid` and the rest still cannot be mapped to a UTM, with or without the option. ### Before you turn it on - **The channel can change.** In the Google Shopping case, once the medium becomes your own value (for example `shopping`), those visits move into the **Paid Shopping** default channel. If you had a custom channel rule matching the feed's tagging, review it. - **Not retroactive.** As with any UTM Mapping change, it applies to new traffic within about 5 minutes; past visits keep the UTMs they had. Full rules, a decision table and the Google Shopping / Performance Max walkthrough: [UTM Mapping](/platform/settings/tracking/utm-mapping#use-case-4--google-shopping--performance-max-product-feed). --- ## Local MCP server — action required if you set it up before June 27 (September 1, 2026) If you connected Sealmetrics to Claude using the **local (npx) MCP server** and configured it before June 27, 2026, your connection has most likely been failing ever since. This affects the local server only: the [remote MCP server](/integrations/mcp-server#remote-mcp-server-recommended) and the Claude Desktop extension are unaffected. ### What happened The npm package was renamed from `@sealmetrics/mcp-server` to `@sealmetrics/mcp` in version 1.3.0, and the old name was removed from the npm registry. Configurations still pointing at the old name receive a `404 Not Found` at startup. The failure is silent — the connector simply shows as unavailable, with no indication of why. We should have announced the rename when it happened. We didn't, and we're sorry for the time it cost you. ### How to fix it Open your MCP configuration file, find the `sealmetrics` entry, and change the package name: ```json "args": ["-y", "@sealmetrics/mcp@latest"] ``` Your API key and site ID stay exactly as they are — nothing else changes. Save the file, quit your client completely and reopen it, then ask "list my Sealmetrics sites" to confirm it works. If it still fails, npx may have cached the broken resolution: run `rm -rf ~/.npm/_npx` and restart once more. Updating brings you to version 1.8.1, which adds live documentation search from the chat, a troubleshooting guide, the marketing analysis playbook, and product-level conversion item data. Full setup guide: [MCP Server](/integrations/mcp-server). --- ## More accurate bounce rate — microconversions no longer affect session counting (August 31, 2026) Bounce rate and engaged visits are now calculated from real page views only. Microconversions (CTA clicks, scroll events, pricing views, banner events…) and conversions are still recorded and keep their full attribution — they simply no longer take part in how a visit is counted. ### What changed - **Only page views count toward engagement.** A visit is engaged when it sees more than one page. Until now other event types could take that role, and the engagement signal was not always picked up by the engagement report. - **Only page views can start or restart a visit.** An event fired on a URL that still carried `utm_*` parameters could be read as a new campaign arrival and restart the session, resetting its page count. - **Microconversions and conversions are unaffected.** Same reporting, same attribution (campaign, landing page, device). ### What you will see in your reports - **Bounce rate drops by around 9% from August 31, 2026.** Your traffic has not changed: engaged visits that were not being counted now are. - **Historical data is not recalculated**, so there is a step in the time series on that date. Take it into account when comparing periods across the boundary. - **Small effect in the opposite direction** on sites with heavy microconversion tracking: a single-page visit is a bounce even if it fires many microconversions, which is what the definition above says. The net effect across accounts is a decrease. **No action is required** — no changes to your pixel, your events or the API. --- ## Privacy hardening — ephemeral session identifiers, click IDs no longer stored (August 24, 2026) Three privacy improvements are now live for all accounts. Reports, historical data and the API keep working exactly as before, and **no action is required**. ### What changed - **Ephemeral session identifiers.** The session identifier used to count visits without cookies now expires and regenerates every day, and the key material behind each rotation is destroyed immediately afterwards. Activity from the same device can no longer be linked across days or across sites — by anyone, Sealmetrics included. - **Click IDs are no longer stored.** Ad-platform click identifiers (`gclid`, `fbclid`, `msclkid` and similar) are used only at the moment of the visit to attribute the channel, then discarded — they are not persisted as a field nor inside stored URLs. Campaign attribution works unchanged. - **Raw User-Agents and IPs removed.** The full browser User-Agent string is no longer retained in analytics storage, and edge access logs no longer record visitor IP addresses or User-Agents. Browser, device and country reports are computed in flight and are unaffected. ### Heads-up for API and BigQuery users If you consume the raw-data endpoints (`/stats/conversions/raw`, `/stats/conversion-items/raw`), the `clid` field no longer appears in the responses. In the BigQuery export, `fact_conversions` no longer receives `click_id`: the column remains in existing tables (queries don't break) and is `NULL` for new rows — and with the click ID out of the aggregation you may see slightly fewer rows, with identical totals. Channel and campaign attribution is unaffected. --- ## Seal AI Private — EU-hosted AI with token packs (July 22, 2026) **Seal AI Private** is now generally available: Sealmetrics' managed AI provider for [LENS](/lens) — processed entirely in the EU (Paris), no prompt retention, and no API key to manage. ### What's new - **Add-on on Growth, included in Scale and Enterprise.** €299/month billed annually upfront (€3,588/year), or €358.80/month on monthly contracts. Not available on Free. - **5M tokens per calendar month** for the whole organization (chat + automated insights), with email alerts at 80% and 100% consumption. - **Token packs**: extra 5M-token packs at €358.80 each (1–10 per checkout) that **never expire** — consumed only after the monthly quota. - **Seal AI Usage screen** (Organization → Seal AI Usage, owner/admin): monthly gauge, daily input/output chart, pack balance and history, and per-site / per-user breakdown. - **BYOK fallback**: when the quota runs out, any user can switch the chat to their own Anthropic, OpenAI, Gemini, or DeepSeek key. Full details: [Seal AI Private](/billing/seal-ai-private) · [LLM Providers](/platform/settings/llm). --- ## Sources report — referral traffic now grouped by domain, GA4-style (July 21, 2026) The **Sources** tab now shows referral traffic as source domains (e.g. `reddit.com / referrer`), unifying historical data under the same convention. The **Referrers** tab keeps its URL-level detail: one row per referring URL. If you query the API, referral rows now appear in `/stats/sources` as domains and are excluded from `/stats/terms`. --- ## Custom Channel Grouping — define your own channels from the dashboard, CSV, or MCP (July 20, 2026) You can now personalize how Sealmetrics groups your traffic into marketing channels. The **Channels** tab in Site settings lets you define your own rules on top of (or overriding) the GA4-style defaults, with a safe drafts → test → publish workflow. ### What's new - **Rule form** for creating custom channels one at a time, with a **rule tester** ("Test a visit") that uses the exact same engine as the pixel. - **Override** button on default channels — pre-fills the form with the default's patterns so you can redirect any built-in channel to one of your own. - **CSV import / export** (Excel-friendly: `,` or `;` delimiters, RFC 4180 quoting, UTF-8 BOM, CRLF) for bulk edits and version control. Also accepts `.json`. - **MCP tools** for AI-assisted rule authoring: `create_channel_rule`, `update_channel_rule`, `delete_channel_rule`, `import_channel_rules`, `test_channel_rules`. All write tools are **draft-only** by design — the MCP can never touch a live rule or activate anything; publishing is always a human action from the dashboard. - **Drafts → test → publish** flow: every new rule is born as a draft and never affects traffic until you flip the **Live** switch. Effective in ~5 min after publishing. ### What stays the same - **No effect on historical data.** Channel classification happens at ingest time; new or edited rules only affect future traffic. - **Defaults still work out of the box.** If you don't create any custom rule, nothing changes for you. Full walkthrough: [Channel Grouping](/platform/settings/tracking/channel-grouping). --- ## Channel classification improvement — more accurate Direct and Referral reporting (July 20, 2026) Following feedback from customers who wanted a cleaner mapping between what our tracker captures and the channel groups shown in the dashboard, we've refined the default classification rules for two channels: - **Direct** — traffic with no referrer and no campaign parameters - **Referral** — visits coming from external sites without UTM tagging The updated rules align our default channel groups with the GA4-style conventions our tracker already uses internally, closing a small gap that had accumulated over successive iterations of the pixel. ### Impact on your reports Starting July 20, 2026, a portion of the traffic previously reported under **Unassigned** now appears in **Direct** or **Referral** in your channel reports. It's the same traffic you were already receiving — simply labeled more accurately from now on. A few details worth knowing: - The change applies only to **new traffic** from the effective date onward. Historical rows keep their existing classification (channels are assigned at ingest time). - If your account uses custom channel rules, those continue to take priority — this update only affects the built-in defaults. - No action is required on your side. If you have automations, alerts or exports built on the exact volume of Unassigned traffic, this is a good moment to review them. --- ## Bot-blocking algorithm update — fewer false positives (June 2, 2026) On **Tuesday, June 2, 2026 at 20:00 CET**, we deployed an update to our bot-blocking algorithm to stop filtering out legitimate human traffic that was previously being misidentified as bot activity. ### What changed The algorithm is now more precise at distinguishing real users from automated traffic, reducing false positives without weakening bot detection. ### Impact on your reports Starting June 2, 2026, you should expect: - A **slight increase in entries and pageviews**, as human visits previously blocked are now counted - A **more noticeable increase in conversions and microconversions**, since affected users were often further along in the funnel - No changes to historical data No action is required on your side. --- ## Attribution: internal hits with UTMs no longer create new sessions (May 25, 2026) We improved how Sealmetrics handles internal navigation that carries UTM parameters. ### What was happening before When a hit on your site contained UTM parameters **and** the referrer was your own domain (i.e. internal navigation), the system treated it as a **new session** and attributed that hit to the traffic source declared in the UTMs. This could inflate session counts and misattribute traffic to campaigns when users were simply navigating across your own pages with UTM-tagged internal links. ### What changed Starting **May 25, 2026**, when a hit has UTMs **and** the referrer is the same domain: - The system now **prioritizes the referrer over the UTMs** - The hit is counted as a **pageview** within the existing session - The **UTM information is ignored** ### Impact on your reports - More accurate session counts — no duplicate sessions caused by internal UTM-tagged links - Cleaner attribution — campaign sources only reflect genuine external entries - Historical data remains unchanged --- ## API: `/exports/*` and `/batch` 403 with API keys — fixed (May 2026) Fixed a permission check on `/exports/*` and `/batch` that required a scope API keys don't carry, returning `403 insufficient_scope` for valid keys. The fix is deployed in production. **No action required** — your existing API key now works on these routes without changes. See the new [API FAQ](/api/faq) for the canonical answers on `account_id` vs `site_id`, event-level conversions, and `/exports/stream` examples. --- ## Sealmetrics V2 is Here (February 9, 2026) **We're thrilled to announce the launch of Sealmetrics V2** — the most significant update since we started. After months of development and feedback from hundreds of customers, we've rebuilt Sealmetrics from the ground up to deliver: - **Faster, cleaner dashboard** — redesigned for clarity and speed - **Smarter attribution** — understand exactly where your conversions come from - **Enhanced privacy compliance** — ready for GDPR, CNIL, UK PECR, and the upcoming EU Digital Omnibus - **New API** — more powerful, better documented, easier to integrate - **Improved tracking** — lighter script, better SPA support, more accurate data Sealmetrics V2 is now the default for all accounts. Your data, your settings, and your tracking code continue to work seamlessly. **Thank you** to everyone who helped shape this release. We're just getting started. → [Explore the documentation](/) to discover everything that's new. --- ## Previous Updates --- ## November 2025 ## Update to the Robot User Agents Database (Nov 21, 6:00 UTC) We have expanded our internal database of robot-related user agents. This update adds **158 new user agents**, improving the accuracy of our identification and filtering systems. This enhancement provides: - More reliable detection of automated traffic. - Higher precision when distinguishing real users from bots. - Better performance across our analytics and security workflows. Check the rest of the documentation to learn how to take advantage of these improvements in your setup. ##Legal Approval for IP-Based Bot Filtering (Nov 18, 20:00 UTC) After a thorough legal review, we now have official approval to implement **IP-based filtering** to improve traffic accuracy—without compromising user privacy. ### How It Works - When a hit arrives, we check whether the IP is in our **bot IP database** - If it matches → the hit is **excluded from your analytics** - If it doesn’t match → we do **not** store the IP, we simply register it as **human traffic** ### Privacy First - We do not retain or track IPs that aren't bots - No identification or storage of human IPs - Full compliance with privacy regulations This ensures: - Better protection of your analytics data - No compromise on user privacy - No personal data is ever stored or exposed It’s a technical improvement — but also a principle: You can have precision without violating privacy. You can have control without crossing the line. --- ## Facebook Traffic Classification Fix (NEW – Nov 17, 19:00 UTC) We've improved how Sealmetrics classifies Facebook traffic to ensure higher accuracy between **organic** and **paid** sources. ### What Was Happening Before A minor issue caused some visits containing the **`fbclid`** parameter (but *without* UTM tags) to be incorrectly categorized as **facebook-ads**. This affected a small portion of traffic, but could distort organic vs. paid Facebook reporting. ### What Changed As of **November 17 at 19:00 UTC**: - Traffic containing **only `fbclid`** and **no UTM parameters** → is now classified as **Facebook Organic** (correct behavior) - Only traffic containing proper **UTM campaign parameters** → is classified as **Facebook Ads** ### Impact on Your Reports - Improved accuracy in distinguishing paid vs. organic Facebook traffic - Expect a slight increase in organic Facebook traffic from this timestamp onward - Historical data remains unchanged to preserve consistency --- ## Performance Improvements (Nov 10, 22:00 UTC) ### 2.5x Faster Data Processing We've significantly optimized our processing infrastructure by increasing core capacity. Your data now processes **2.5 times faster**, meaning real-time dashboard updates and instant report generation. **Benefits:** - Faster dashboard loading times - Real-time data updates - Instant report generation - Improved overall platform responsiveness --- ## Facebook Ads Attribution Update (Nov 13, 19:00 UTC) **Warning:** As of this release, the `fbclid` parameter is no longer used to identify Facebook Ads traffic due to its lack of reliability and consistency. **What this means for you:** - Facebook Ads traffic now **requires properly configured UTM tags** for accurate attribution - Ensure your campaigns include parameters such as: - `utm_source=facebook` - `utm_medium=paid` - (or equivalent) - This ensures consistent, accurate attribution and full control over your data **Recommendation:** Review and update your Facebook Ads campaigns with correct UTMs to maintain full visibility. **Tip:** --- ## Migration Guide If you're currently relying on `fbclid` for Facebook Ads attribution, follow these steps: 1. **Audit your campaigns:** Check all active Facebook Ads campaigns 2. **Add UTM parameters:** Configure UTMs in your Facebook Ads Manager 3. **Test:** Verify traffic attribution inside Sealmetrics 4. **Monitor:** Ensure continuity in your reporting Need assistance? [Contact our support team](mailto:support@sealmetrics.com)