Changelog

What is new

• The settings page of the Shopify app is closed and now answers "not found". Nothing in Pulse used the values on that page: conversions from Shopify are only ever sent with the settings of the client in TJDA Pulse.
• After installing the app, TJDA Pulse shows a short confirmation instead of that page.

What you get

• Store settings can no longer be viewed or changed by someone who only knows the store's domain.

What is new

• Every form and button on the Settings page now carries the client it was opened for. If you open another client in a second tab and then save in the first tab, the change either goes to the client that tab shows, or nothing is saved and the page says "This page was opened for another client. Nothing was saved. Reload Settings and try again."
• This covers all settings (stats, Google tag, Google Ads, LinkedIn, OpenAI, Meta, GA4 and Microsoft), the browser key, the client type, the report types, the backfill limit, conversion steps, step templates and the acceptance of the Data Processing Agreement.
• A Settings page that was already open before this update shows the same message once; reload it and save again.
• After saving, Settings stays on the same client.

What you get

• A pixel ID, token or other setting is saved only for the client the page was opened for, also when you work with several clients in different tabs.

What is new

• The Google uplift card counts a delivered conversion only when every consent field in it is an explicit yes, exactly as the rest of Pulse does. Until now it read only one consent field (the other was ignored) and accepted only the value true, so a conversion with a yes in one field and a no in the other could count as consented, and a consent given as text ("yes") did not count.
• This can move the delivery start week and the delivery line on the card, and with it the comparison. Earlier weeks are recalculated the same way; the card says "Calculation changed on 06-10-2026".
• If the uplift cannot be calculated because of a data error, the card now says so ("Uplift not calculated (data error)") instead of leaving the section out.
• The per-euro figure now needs at least 4 full weeks with spend in the baseline (was 3); a week counts as full from the first Monday on or after the first day of spend data in Pulse. If the spend data starts later than the baseline (no rows before that date: either not synced, or no spend), the card shows the change in conversions instead of a per-euro percentage and says so ("Spend incomplete before …"). The same applies to the comparison with last year.
• The week of the measurement start and the week before are left out of the comparison, and the card says so.
• The card compares like with like: the baseline starts once every conversion action in the set has data each week ("baseline from …"). If an action only gets data later, the card says "Action set changed on … — not like for like" and shows no percentage.
• The card warns when the ratio of Google conversions to the leads Pulse receives shifts by a factor of 2 or more ("Measurement changed around …", with the connector version before and after when known).
• Per client, TJDA can set the conversion actions of the card, record measurement changes (GTM container, second server-side stream, tag, conversion action, cookie banner) and exclude periods from the comparison ("excluded: …"); the card shows them. An invalid setting is never guessed: the card says "Uplift settings invalid".

What you get

• The uplift card uses the same consent rule as every other figure in Pulse, shows a per-euro figure only when the spend behind it is complete, and never disappears silently.

What is new

• When Settings refuses to save a form (for example because an ID is already used by another client in Pulse), the form now keeps what you entered and shows the reason next to the field, not only at the top of the page. Nothing in that form is saved, as before.
• Secret fields such as the GA4 API Secret are never shown back: enter them again before you save once more.

What you get

• A refused value no longer looks as if it disappeared: you see what was refused and why.

What is new

• The GA4 and Microsoft forms in Settings now carry the client they were opened for. If you opened another client in a second tab in the meantime, saving the older tab is refused when it would otherwise have saved into that other client ("This page was opened for another client. Nothing was saved.").
• After saving, Settings stays on the same client.

What you get

• Working with several clients in several tabs can no longer save settings into the wrong client from these forms.

What is new

• The Pulse GTM container template is now downloaded from Pulse itself (log in first), instead of from a shared drive link. The setup guide links to it.

What you get

• You always get the current version of the template.

What is new

• The GA4 Property ID, the Web Property ID and the Search Console property can now only be set by TJDA. In Settings you see which property is connected; to connect or change one, send it to TJDA support.

What you get

• Pulse reads GA4 and Search Console with TJDA's own service account, so only properties that belong to your account are connected.

What is new

• Before fetching Search Console data, Pulse now checks which properties it has access to. If it has no access to your property, or the property in Settings is written in a different form than the one Pulse can use, the Audit shows a warning with the cause and what to do, instead of reporting the connection as working or blaming low organic traffic.

What you get

• You see straight away why Search Console data is missing and how to fix it.

What is new

• Accounts that use their agency’s Google Ads connection now get the same Google Ads reporting data as accounts with their own connection: campaign results, conversions per conversion action, product and ad performance, impression share and search terms. The daily update covers the most recent four weeks; older months can be added on request.

What you get

• Google Ads appears in the dashboards and reports of these accounts, next to the other channels.

What is new

• The Audit check "Google Ads connection" showed formatting codes around the agency name (for example <strong>). It now shows the name as plain text.

What you get

• The check reads as intended.

What is new

• If no clients are linked to your account yet, signing in now opens Account with the notice "No clients linked yet", instead of ending in a redirect error in the browser.

What you get

• New agency users can sign in and manage their account before their clients are linked.

What is new

• An agency user who has been given agency management rights by TJDA sees a "Google Ads (MCC)" card in Account. From there the agency connects its Google Ads manager account once for all its clients, and can revoke that connection in Pulse.
• Revoking in Pulse does not change anything at Google. To also remove Pulse's access at Google, remove Pulse under third-party access in the Google account that was used to connect.

What you get

• The agency signs in with its own Google account in its own browser; nobody else has to log in for it.

What is new

• For accounts that use their agency's Google Ads connection, only TJDA can change the Google Ads customer ID in Settings, after checking that it is an active client account under the agency's manager account. Saving Settings without changing the ID works as before.
• The Audit has a new line, "Google Ads connection". It says whether Google Ads is connected through the account's own Google authorisation, through the agency's manager account, or through the platform, and why there is no connection when there is none (for example: the agency connection was revoked, or the customer ID is not verified under the agency's manager account).

What you get

• You can see at a glance who gave Pulse access to your Google Ads account, and a lost connection never goes unnoticed.

What is new

• When it has been checked in the ad platform that a channel had no spend this year before its first data date, the dashboard counts the days before that date as €0. The channel row then says "No spend before" and the date, "(checked)", and pacing gives a verdict again, also on the totals that include that channel.
• This only applies when the checked date is exactly the channel's first data date this year. Any other date is not applied, and a notice at the top says why.

What you get

• A channel that really started halfway through the year is compared with its budget again, instead of showing "Incomplete data" all year.

What is new

• When a channel's first spend data this year is later than the start of the period, its row now says so under the channel name ("Spend data from" and the date), and pacing shows "Incomplete data" instead of Below, On or Above target. The amounts stay visible. The same applies to the total, market, campaign type and partner rows that include that channel.
• The notice at the top now says what a missing start means: there are no rows before that date, either because they were not synced or because there was no spend. It looks at this year only, so data from an earlier year no longer hides a gap at the start of this one.

What you get

• A channel that was connected halfway through the year no longer looks like it is underspending its budget.

What is new

• For accounts with a budget dashboard, Microsoft Ads and ChatGPT Ads can now show registrations and cost per registration, where the budget plan names what counts as a registration. Until now both channels showed registrations as "not available".
• Microsoft Ads: registrations come from one conversion goal, counted in all conversions. Microsoft reports a conversion on the date of the ad click, while Google Ads registrations in the dashboard are counted by conversion time, so recent Microsoft days fill in later. The footnotes say this.
• ChatGPT Ads reports conversions per campaign, not per conversion goal. The dashboard counts click-through conversions only; view-through conversions are shown next to them but not counted, so the dashboard can show fewer registrations than the ChatGPT Ads interface. The footnotes state which conversions are counted as registrations and on which date they are counted.
• A missing registration figure is no longer counted as zero, on any channel. When a platform did not deliver the registration figure for a campaign on a given day, that campaign-day is left out of the registrations (for a channel that reports registrations per account: that day), and the number of such campaign-days is shown next to the figure and in the notices at the top. Where they fall, cost per registration is not shown, because the spend of those days would be counted without their registrations. A figure made up only of such days is shown as "n/a". ChatGPT Ads is the exception: its spend and conversions come per campaign and day together, so its cost per registration uses only the campaign-days with a figure.

What you get

• Cost per registration now covers Microsoft Ads and ChatGPT Ads too, with the differences between the platforms written out — and a gap in the data shows up as a gap, not as fewer registrations.

What is new

• A dashboard with a search terms table stopped loading at that table, because of a typing error in the column name for impressions. It now loads.

What you get

• Search term tables on dashboards work.

What is new

• The developer guide now says that Pulse itself empties click IDs, the Meta browser ID, the GA client and session ID and the hashed fields on receipt when an event arrives without consent, and that the Audit shows how often that happened. Fields under other names are stored as sent, so leaving identifiers out without consent remains your integration’s job.

What you get

• The guide describes what the platform already does since 28 September.

What is new

• Audit texts no longer mention the internal environment name (such as production); only a Pulse administrator sees it. The same applies to the reporting-sync reason in the Action list.
• The check Browser key requests is now always listed. Without requests in the last 7 days it shows as not applicable instead of being left out.

What you get

• A clearer Audit, with every browser-key check visible even before you create a key.

What is new

• For every lead (event type lead, from the WordPress connector or your API integration), GA4 no longer receives a transaction_id and Meta no longer receives an order_id, a value of 0 or a currency without a value. Microsoft Ads now receives the lead’s event ID as transactionId, the same key Google Ads already used. An order_id you send with a lead is no longer passed on. Until now each connector lead also carried a separate, random order number that meant nothing to the ad platforms.
• Purchases are not affected.

What you get

• A lead now has one key: the event ID, wherever a platform takes one; no platform receives a separate order reference for a lead.

What is new

• When a request to the Pulse MCP connector fails for an internal reason, your AI assistant now gets a fixed message (the request could not be completed) instead of the technical error. Validation messages for dashboards stay as they were.
• If the connector cannot reach its data, it answers with a clear temporarily unavailable message instead of an empty or broken response.

What you get

• Internal details of the platform never reach an AI assistant or its conversation history.

What is new

• When an event arrives without marketing consent, Pulse now empties these fields before storing it: the click IDs (gclid, wbraid, gbraid, fbc, fbp, li_fat_id, msclkid, oppref, obref), pulse_ids, the GA client_id and session_id, and the hashed fields. Until now your own API integration could store them without consent, and the WordPress connector sent the GA client and session ID without marketing consent (as a statistics identifier); those are now emptied too. For Shopify and Lightspeed orders the same rule now applies, including the GA client and session ID; their click IDs and hashed fields were already emptied.
• For your API integration, the channel of such a conversion is kept, so channel cards and missed-conversion counts do not change. For Shopify orders without consent that carry a click ID on the order itself (through the Pulse checkout bridge), Pulse now also keeps which kind of ad click ID it was (Google, Meta, Microsoft or LinkedIn), without the ID itself. From the date of this update, such orders can move from the anonymous variant of a channel (or from Unassigned, when there was no channel signal) to Paid Search, Paid Social or LinkedIn, and they count in the missed-conversion numbers and in the gclid coverage and Consent-capture parity checks of your Audit. Click IDs from the Shopify pixel and from Lightspeed tracking are only used with consent, also when consent was withdrawn after the click. The cookie-extender card now lists these purchases separately: without consent Pulse keeps no click history, so their click age is unknown. Events stored before this update are not changed.
• Your Audit shows how often Pulse emptied these fields on receipt (Identifiers removed without consent).

What you get

• For visitors who did not give marketing consent, the click IDs, GA client and session ID and hashed fields listed above are no longer stored in your events, whatever your integration sends in those fields.

What is new

• Back-ups: the DPA now states the actual schedule. Back-ups of the whole server are made every four hours and weekly, and are kept for at most six weeks (v3.3 said seven days). Deleted data stays in the database’s transaction logs for up to 30 days and in the back-ups until they expire, and is not restored from either; if a back-up is ever restored, earlier deletions are carried out again before the data is used.
• Web-server logs: access logs keep the IP address only in truncated form (with the request line, keys and tokens masked, the referring page and the user agent); error logs may contain the full IP address and the request URL. Both are kept on the server for at most eight days, and in the back-ups for up to six weeks.
• Deletion requests: Pulse keeps a register of deletion requests outside the server, accessible only to TJDA and without personal data of your visitors: it records the client, the date and your written instruction, so that a deletion can be carried out again from that instruction if a back-up is ever restored.
• Measurement without consent (3.4): the DPA now lists what the anonymous GA4 count does contain (event name, value, currency and per product line the product code, quantity and price), next to what it never contains.
• New 3.4a: with consent but without a usable GA4 client ID, Pulse derives a replacement from the event’s own ID, not from the visitor or the device.
• Hashed fields (3.6): for the Shopify and Lightspeed integrations Pulse hashes the email address, phone number and customer ID or order reference itself on receipt; for the API it still never hashes a readable value.
• Categories (3.2 and 3.3): the Meta browser ID (fbp) and the hashed customer reference (external_id) are now listed under data processed with consent. The DPA now also states that without consent Pulse clears these identifiers, the GA client and session ID and the hashed fields on receipt, whatever your integration sends in those fields (see the entry on consent of the same date); events stored before this update may still contain them. Other fields your API integration adds are stored as sent. An ip or user_agent field that your API integration sends is not cleared: it is stored as sent and, with consent, forwarded to Meta; v3.3 said the IP address was never in stored event data.
• Versions v3.2 and v3.3 had no changelog entry of their own; this entry covers the DPA as it stands now.
• Privacy policy (version 2.1): the back-up and web-server log periods now match the DPA.

What you get

• The DPA describes what Pulse actually does today, including the back-up and log periods your privacy officer will ask about.

What is new

• Settings has a new Browser key card. A browser key starts with s2sb_ and is meant for the Pulse browser tag, which feeds Pulse’s browser-twin count (the uplift figure). The tag is not available yet; until then, use the key only when your Pulse representative asks for it. Your API key never goes in the browser.
• A browser key only works on the event endpoint. Pulse treats every event sent with it as a browser event, keeps only the event type, event_id, consent and time, never forwards it to an ad platform, and refuses an event without event_id. It has its own rate limit, counted separately from your connector.
• Pulse shows the key only once. If you replace it, the previous key keeps working for 24 hours so the tag can be updated, or you can stop it at once.
• Your Audit shows browser events that still arrive with your API key, and browser-key requests that were refused, hit the rate limit or came from another site.

What you get

• Browser events no longer need your API key in the page, so nobody visiting your site can read a key that sends conversions to your ad accounts.

What is new

• Developer guide: the API key section warns that the key never goes in the browser (Google Tag Manager, JavaScript, page source), and to ask for a new key if it was ever visible.
• Developer guide: the value "browser" for source is reserved for Pulse’s own tooling; do not send it. The response table says the same.
• Setup guide: a tag in your GTM container that sends to a Pulse address or contains your API key should be paused, and the key rotated.
• Setup guide: Pulse’s uplift figure will need a separate Pulse browser tag with its own browser key. That tag is not available yet; until then, treat the uplift figure as not available.
• Developer guide: the demo-request example lists the three steps: the event type, a conversion step on the form_id, and the LinkedIn lead conversion in Settings.
• Developer guide: click IDs (gclid, fbc from fbclid, msclkid and the others) are sent only for visitors who gave marketing consent; without consent they stay out of the payload.

What you get

• Your API key stays on your server, where nobody visiting your website can copy it and send conversions to your ad accounts.

What is new

• The API endpoint for custom integrations now answers 400 (Invalid payload) to an event whose event_id is longer than 64 characters. Before, the call failed on storage.
• Shopify and Lightspeed: such an event is stored without a key instead, and your Audit counts it under Events without event ID. None of the current integrations comes near the limit.

What you get

• The key Pulse stores and forwards is always exactly the one you sent, so the browser and the server keep deduplicating.

What is new

• Developer guide: the GA4 cookie example works when copied, reads both cookie formats (GS1 and GS2) and takes the session only from the Pulse GA4 property.
• Developer guide: the dataLayer example pushes s2s_lead and s2s_purchase, the events the Pulse GTM container fires on.
• Developer guide: the response table lists every answer of the endpoint, including 204, the staging answer and the answer to a browser event. New: how the event type decides what each platform receives, a demo request as example, offline conversions, and the limits of event_id, value and timestamp.
• Setup guide: every Google Ads conversion gets a second browser tag to the Pulse action, with the same Transaction ID as the tag to your browser action. That tag sends from the browser to your own Google Ads account; TJDA does not receive its individual hits, only the daily totals per action it already reads for the weekly check.
• Developer guide: the pre-flight asks to connect GA4 only after it, like the ad platforms, and test events carry an event_id starting with preflight-. Offline conversions are marked as not available yet.

What you get

• The examples in the developer guide are the ones Pulse tests on every change, so what you copy is what the endpoint accepts.

What is new

• For a lead, Pulse now always sends the event_id as the Google Ads transaction ID, also when the lead carries an order_id. That is the same key the browser tag sends for leads.
• A lead without an event_id is no longer sent to Google Ads, even when it has an order_id. The Audit lists it under Events without event ID.

What you get

• Server and browser send the same key for a lead, so Google Ads can deduplicate them within one action.

What is new

• Pulse now recognises a repeated event by your account, the event type, the source and the event_id together. Before, only the event_id and the source counted, so an event of another type or from another account with the same event_id could be discarded as a duplicate.
• An event_type that is neither text nor a number, or is longer than 64 characters, is refused with 400.

What you get

• No event is lost because another event happened to carry the same ID.

What is new

• The detail page of each Action list item now lists 3 to 5 concrete checks, in the order you do them, for the signal and the ad platform of that item (Google Ads, Microsoft Ads, Meta, LinkedIn or ChatGPT Ads). Where it helps, a check uses the figures of the item, such as the week the change started or the share lost to budget and to rank.
• A check names the place in the ad platform where you find it only when the platform’s own help pages describe that path; otherwise it describes what to look at.
• The card in the list shows the first check and how many more are on the detail page.

What you get

• You know where to start in the ad platform, instead of a single general hint.

What is new

• Selecting a signal filter (Spend spike, CTR drop and the others), on its own or together with a status count, now hides the cards that don’t match. Before this fix, cards without the selected signal stayed visible in every section that still had at least one match. Filtering by a status count alone already worked.

What you get

• The Action list narrows to the signals you select, also when you share or reload the filtered link.

What is new

• The Audit now checks, over the last 7 full days and today, how many purchases with marketing consent reached Pulse without a usable GA client ID. More than 5% over the whole period, with at least 3 such purchases, is a fail; more than 5% on a single day is a warning. The check shows the number of purchases, the worst day and the connector version or source that sent them. GA4 cannot link such purchases to the visitor’s session or traffic source.
• Accounts without a Pulse GA4 property see this check as not applicable: nothing uses the GA client ID there.
• For shops on WooCommerce connector 1.3.3 up to 1.3.7 this check turns red once at least 3 consented purchases have come in: those versions do not pass the GA client ID on purchases.

What you get

• Missing GA client IDs show up in the Audit, instead of quietly lowering what GA4 can attribute.

What is new

• Correction to the entry of 16 September (“GA4 without consent: anonymous pings only”). That entry said the Pulse GA4 property keeps showing the full number of conversions. For WooCommerce shops on connector 1.3.3 up to 1.3.7 that was not true for purchases with marketing consent: the connector sent them without a GA client ID, GA4 accepted the hit but did not count it, and the property mainly showed the purchases without consent.
• When a consented conversion arrives without a usable GA client ID, Pulse now sends it to the Pulse GA4 property with a stand-in ID derived from the event itself (nothing about the visitor), together with its revenue and transaction ID, in the form GA4 is expected to count. It will most likely show as a new user without a session, so GA4 cannot attribute a traffic source to it. Conversions without any client ID that previously all landed on one placeholder user now each get their own stand-in ID, so the user count in the Pulse GA4 property can rise.
• A consented conversion that has neither a GA client ID nor an event ID is no longer sent to the Pulse GA4 property: there is nothing to derive a stand-in ID from. The Audit lists such events under Events without event ID.
• Purchases from the affected weeks are not sent again. A connector update that restores the GA client ID and session follows separately.

What you get

• Consented purchases reach the Pulse GA4 property again, in the form GA4 is expected to count, without waiting for the connector update.

What is new

• Correction to the entry of 22 September. That entry said ChatGPT Ads spend, clicks and conversions come into Pulse. For accounts that had added a ChatGPT Ads reporting API key, no ChatGPT Ads figures were stored: Pulse called the ChatGPT Ads API at an address without its version number, the API refused the very first request, and the run stopped there. The Audit showed the ChatGPT Ads sync as failed, but without the cause; it was never counted as zero. Pulse now uses the documented address, and asks for conversions per day in the format that part of the API expects (checked against the ChatGPT Ads API documentation on 23 September).
• A conversion day runs from midnight to midnight in your ad account’s time zone. On the days the clocks change, that day is 23 or 25 hours long, and Pulse asks for exactly that.

What you get

• ChatGPT Ads spend, clicks and conversions now reach your budget dashboard and weekly report from the next nightly run, for the last four weeks.

What is new

• For accounts with a budget dashboard: markets can now be recognised from any word in the campaign name, whether it is separated by |, _, - or a space, including country codes that belong to a market in your budget plan. A campaign that points to more than one market still shows up under Not classified, with the reason.
• Campaign types can follow a fixed order of precedence: when a name fits more than one type, the first one in that order wins, instead of the campaign falling out of the split. Each channel can have its own campaign-type split. The terms, codes and order are set per budget plan and listed in the footnotes of the dashboard.
• A campaign that fits nowhere is never quietly moved somewhere: it stays listed under Not classified campaigns, with the reason next to it. The same goes for a campaign whose name points to a campaign type its channel does not have.

What you get

• More of the spend lands in the right market and campaign type, so the pacing per market and per type reflects the budget plan — and what the dashboard cannot place is still in plain sight.

What is new

• Correction to the entry of 22 September. That entry said Microsoft Ads figures come in per campaign and per ad group. The ad group part did not happen: Microsoft refused that report because Pulse asked for one column under a name that report does not use, so no ad group figures were stored. The Audit showed the report as not retrieved; it was never counted as zero. Pulse now asks for the column under the right name, and our tests check every requested column against a copy of Microsoft’s published list for that report (checked on 23 September). Ad group figures are stored from the next nightly run for later use; no page in Pulse shows them yet. Campaign figures, conversion goals and spend were not affected by this.
• When Microsoft refuses a report, the Audit now shows Microsoft’s error code with a short explanation in plain language instead of only a number, so you can see which error Microsoft returned.
• The report time zone under Settings is now a list of the time zones Microsoft accepts, instead of free text. A value that is not on that list is refused when you save. An older value that Microsoft does not know is shown as invalid, not silently replaced.

What you get

• When Microsoft Ads reporting goes wrong you now see why, and the time zone can no longer be mistyped.

What is new

• Pulse already sent conversions to Microsoft Advertising and ChatGPT Ads. From now on it also reads the other direction: spend, impressions, clicks and conversions per day, per campaign and per ad group. The nightly run keeps the last four weeks up to date, because both platforms revise their figures afterwards. Earlier days are not there automatically — they can be filled in on request, up to the limit set for your account.
• Because of that, Microsoft Ads now shows real spend and pacing in the budget dashboard instead of "Not connected", ChatGPT Ads appears there as a channel of its own, and both show up in the weekly report and in the per-platform comparison. You can also ask the AI assistant you connected to Pulse for campaign figures filtered to either channel. Saved dashboard widgets do not have metrics for these two channels yet.
• A missing figure stays empty, and is never shown as zero. If a platform does not answer for a day, or does not supply a column, Pulse leaves that number blank instead of counting it as zero, and the Audit names the days and the reason. This applies to spend, impressions, clicks and conversions alike, and to the figures derived from them: a week-on-week comparison stays empty when either week is missing a figure, and a subtotal that leaves campaigns out says how many. A gap in the data is not a drop in performance, and the two should never look the same.
• Each day is stored together with the time zone it was measured in. Microsoft in particular does not report days in UTC: it uses the time zone of the ad account, and without one it would silently fall back to US Pacific time, shifting every day by nine hours. Pulse asks for the days in your account's time zone, checks afterwards that the report really used it, and stores that zone with every row. If the time zone is missing or does not match, no figures are stored at all for that run.
• For ChatGPT Ads, click-through and view-through conversions are kept separately next to the total. Pulse delivers click conversions and cannot see view-through, so the distinction matters when you compare the two. ChatGPT Ads reports conversions per campaign rather than per conversion goal, so registrations stay shown as "not available" for that channel rather than as zero.

What you get

• Your budget dashboard, your weekly report and your AI assistant now cover Microsoft Ads and ChatGPT Ads as well, so the spend side of your reporting is complete instead of missing two channels — and when a figure is missing, you can see that it is missing.

What is new

• Pulse now collects Google Ads impression share for your Search campaigns every day: how often your ads showed compared to how often they could have shown, split into the top of the page and the very first position, plus how much you missed because of your budget and how much because of your Ad Rank. The figures are collected per campaign per day, starting from the day Pulse begins collecting them; the daily run keeps the last four weeks up to date, because Google revises these estimates afterwards. Earlier days are not there automatically — they can be filled in on request, up to 16 months back, depending on the limit set for your account.
• A new get_impression_share tool makes them available to the AI assistant you connected to Pulse, so you can ask questions like "what is my impression share on branded campaigns?" and get an answer over any period you choose, per campaign, per week or per day. You can filter on part of a campaign name.
• Totals are weighted, never averaged. Impression share cannot be added up: it is a fraction whose denominator — the impressions you were eligible for — Google does not report. Pulse reconstructs that denominator per campaign per day and adds those up, so a campaign with ten times the volume weighs ten times as heavily. Averaging two percentages gives a different and wrong number, which is why every row also shows its eligible impressions: if you re-group the rows yourself, weight them with that column.
• Where Google will not give a number, Pulse does not invent one. Google reports any share below 10% as a fixed placeholder, which means the real value is unknown and the row cannot be weighted. Those rows are left out of the total and counted separately, so you always see how much of your volume sits outside the figure instead of quietly getting a different number. The answer also names the days it actually covers, so a gap in collection is visible rather than silent.
• These are Google's own estimates about its own auction. They say nothing about what Pulse measures or delivers, and a weighted total reconstructed from rounded estimates will not match the Google Ads interface to the last decimal.

What you get

• You can ask your AI assistant how much of the available search volume you are actually winning, and how much you are losing because your budget ran out versus because your Ad Rank was too low, without exporting anything or averaging percentages by hand.

What is new

• Every call to the Pulse webhook is recorded in an API log, together with the IP address it came from. For most shops that is the address of the shop server, but a browser tag that posts straight to the webhook sends the address of the visitor instead — also for visitors who did not give consent. From now on that address is shortened before it is written: the last octet of an IPv4 address, and the last 80 bits of an IPv6 address, are set to zero. What is stored is a network range rather than a full address. Nothing in Pulse uses the address itself: rate limiting counts per account, and no page, report or export shows it. The only thing that reads the column is the new Audit check below, which counts entries that still have one.
• The stored address is also cleared once the log entry is 90 days old. The log entry itself stays, so the number of calls, the endpoint and the response code remain available; only the address goes. A new API log IP retention check in the Audit shows whether any of your entries are past that term, and when the daily task that clears them last ran — including when it has not run yet. A cleanup that stops is visible there instead of silent.

What you get

• Less personal data about your visitors is stored, and what is stored does not stay indefinitely, without losing anything Pulse measures or reports.

What is new

• The update below, from earlier today, checks the six hashed fields on arrival. It left one route open, and this closes it: a payload can also carry a plain email or phone field instead of the hashed ones. There is no valid content for those two — a readable address or number belongs in email_hash or phone_hash — so from now on the value is emptied on receipt. It is not stored, and it is not sent to any ad platform.
• Pulse no longer hashes those values for you. Until now it did: the Meta path hashed the email address and the phone number itself, the LinkedIn path the email address, and the same fallback sat in the Google Ads API code. That is exactly what the processing agreement rules out — contact details are processed in hashed form only, so the platform should not be handling the readable value at all — and it hid the mistake from the integration that made it.
• Your Audit gets a second check for this, Readable email or phone in the payload, separate from Unhashed values in hashed fields. Two different mistakes need two different fixes, so they are reported separately. Like the other one, it names the field and the number of events, never the value, and it separates events emptied on receipt from older events that still carry the value in storage.
• Nothing changes for the WordPress connector, the Shopify app or the Lightspeed integration: none of them sends these fields in any released version we can check. This matters only for integrations that call the webhook API directly and build the payload themselves. If yours does, and it sent a plain email or phone, its match quality at Meta and LinkedIn will drop until it sends the hashed fields — which is why it is in your Audit rather than happening quietly.
• One more path loses fields here: the old, no longer supported PHP SDK webhook endpoint, which sends a plain email address and phone number alongside the plain customer ID it already lost in the update below. It calls the ad platforms directly rather than through the webhook API, so none of this shows up in an Audit. It is not a supported route.

What you get

• A readable email address or phone number sent to the webhook API can no longer be stored by Pulse or hashed on your behalf — and an integration that still sends one is visible in your Audit instead of silently working differently than you think. (The Shopify and Lightspeed integrations are different by design: there Pulse receives the order from the shop platform and does the hashing for you, because there is no other place to do it.)

What is new

• The fields that carry contact details — email_hash, email_hash_ms, email_hash_oai, phone_hash, phone_hash_oai and external_id — are now checked on arrival. They must contain a SHA-256 hash: 64 hexadecimal characters. Anything else, such as a readable email address, a phone number or a plain customer number, is emptied straight away. It is not stored, and it is not sent to Google Ads, GA4, Meta, LinkedIn, Microsoft Ads or ChatGPT Ads.
• In these six fields, Pulse does not hash such a value for you. For the email and phone fields that is what the processing agreement requires: contact details are processed in hashed form only, so the platform should not be handling the readable value at all. For external_id the reason is data minimisation — Microsoft Ads and ChatGPT Ads receive that field exactly as you send it. And in both cases, hashing it quietly would repair the mistake out of sight, so nobody would ever fix it. Instead the Audit gets a new Unhashed values in hashed fields check that names the field and the number of events, never the value itself. It also separates events emptied on receipt from older events that still carry the value in storage.
• A hash sent in upper case is accepted and stored in lower case, which is the form the ad platforms match on. Fields left empty stay empty and are not an error: that is what an event without marketing consent looks like.
• Nothing changes for the WordPress connector, the Shopify app or the Lightspeed integration. Those hash the values themselves, and have done so in every released version we can check. This check matters for integrations that call the webhook API directly and build the payload themselves — including the old, no longer supported PHP SDK webhook endpoint, which sends a plain customer ID in external_id and will lose that field from now on.
• What this release does not cover. A payload can also carry a plain email or phone field instead of the hashed ones. Those are an older route that this check does not touch: Pulse still stores such a value instead of rejecting it, and its Meta path hashes the email and phone number itself, its LinkedIn path the email. The same fallback sits in the Google Ads API code, a route that does not run today. We are handling that separately; until then, do not send them.

What you get

• Contact details can no longer leave Pulse unhashed through a hashed field because of a mistake in an integration — and if an integration makes that mistake, you see it in your Audit instead of never hearing about it.

What is new

• The agency that manages your account has always been able to look up your connector API key in Settings — that has not changed.
• For installing or reconnecting the plugin on many sites at once, TJDA can now open a temporary overview that lists the keys of all clients of that agency. It is off by default, runs for a limited number of days and then closes by itself.
• While that overview is open for your agency, the Audit shows an informational line under Data isolation with the date it closes. Every view of the overview is logged.

What you get

• You can see for yourself when your connector key is part of such an overview, and until when.

What is new

• Linking an ID that can affect another client’s numbers in Pulse is now refused when another client already uses it. This covers GA4 properties and measurement IDs, Search Console properties, the Google Ads customer ID and conversion ID (AW-…), Meta ad accounts and pixels, and LinkedIn ad accounts and conversions, in Settings and in funnel steps. If another client already uses it, you get a clear message and nothing in that form is saved. For Search Console this also covers overlap: a domain property includes all its subdomains, in both directions.
• New entries of these IDs must have their expected format, for example act_123456789 for a Meta ad account. Meta and LinkedIn reporting only uses that format; if a stored Meta or LinkedIn ad account ID has another format, that reporting is paused for your account and the Audit tells you what to correct. Other stored IDs in an older format keep being used as before, and the Audit suggests the expected format.
• The Audit has a new Data isolation check. It shows when one of these IDs is also linked to another client, or comes from a platform-wide default, and when a stored ID cannot be checked.

What you get

• A new link to another client’s account is refused, and an existing shared ID shows up in the Audit instead of going unnoticed.

What is new

• When someone clicked an ad and then filled in a form, that click was recorded on the device but did not make it into the lead we send. The order path already looked in four places for a click ID — our own store, the plain cookies, the advertising platform’s own cookie, and WooCommerce’s attribution cookie — while the form path looked in only one. If that one place was empty, and it often is behind a page cache or a CDN, the lead went out without any proof of the click. There was no error message: a missing click ID looks exactly like “there was no click”.
• A second gap made it worse. A click from an iPhone gives wbraid or gbraid instead of the usual gclid, and those two fields did not exist in a lead at all. Every iOS lead therefore lost its click, even on shops where everything else worked.
• Both paths now read from the same place, so a consented lead carries the same click fields as an order, including the click history that records when each click happened. Nothing changed for visitors without marketing consent: a lead then carries no click field at all.
• Correction to the 1.3.6 note. That release said a click time we cannot use is “no longer quietly replaced by the current moment”. That is true everywhere except one route: a click recovered from WooCommerce’s own attribution cookie still gets the current moment when its recorded time cannot be read, which makes it look like a click of today. That applies both to the click history we store and to what we send on. We found this while building 1.3.7 and deliberately did not fix it here — a first attempt turned out to cost more measurement than it repaired. It is written up and is being handled separately.

What you get

• Google can now match leads to the actual ad click instead of estimating them, so the contribution of your campaigns to form submissions becomes visible and measurable.

What is new

• The Meta click cookie stores its timestamp in milliseconds, every other channel in seconds. Until now that value was stored as-is, so a Meta click always looked like the most recent one — which pushed those conversions into the shortest bucket of the Cookie extender card and credited them to Meta. There was no error message; the numbers simply looked plausible.
• Time values coming from any external source are now converted to seconds on the way in, and a value we cannot use is no longer quietly replaced by the current moment. Conversions with an unusable click time are counted separately on the card as not determinable, so a number never drops without an explanation, and the Audit gained a Click time usable check.
• The correction applies to earlier periods too: the buckets are recalculated from stored data every time you open the page. A period you looked at before 18-09 can therefore show a different — and now correct — distribution.

What you get

• The click-age distribution and the channel it names are now right, including for conversions that involved a Meta click.

What is new

• Until a visitor answers the consent banner, the connector now stores channel and click information for that browser session only — a cookie without an expiry date and a session-scoped mirror. Nothing is written that is meant to persist, so refusing or ignoring the banner leaves no stored expiry date behind. (Two known browser limits: a browser set to restore the previous session may bring session cookies back, and session storage is per tab.)
• The moment a marketing consent signal is detected, the very same values captured on arrival are written again with the full lifetime, so attribution inside the session is never lost and returning visitors keep their click history. The decision uses the connector’s server-side consent detection, which covers every supported consent platform — not a smaller second check.
• Correction to the 1.3.3 note. That release said first-visit click IDs survive “without ever storing an identifier before the yes”. That was too broadly worded: the recapture it described worked, but the individual click-ID cookies and the landing-page channel cookie were still written with a long lifetime before consent. From 1.3.5 the claim holds as stated.

What you get

• A refused or unanswered banner now leaves nothing behind that outlives the browser session, while consented visitors keep exactly the attribution they had.

What is new

• When Pulse loads your history (Search Console, GA4 landing pages, Google Ads, Meta, LinkedIn), it now goes back twelve months by default instead of as far as each platform allows.
• The limit is set per account, up to sixteen months (all that Search Console keeps). A load that would start earlier is refused with a clear message rather than silently shortened. Your daily sync is not affected.

What you get

• A new account starts with a full year for comparison, without an unplanned sixteen-month import slowing the first days.

What is new

• A new Budget tab under Dashboards (for accounts with a budget plan) shows spend against budget with a pacing meter, registrations and cost per registration: year to date, last 30 days, per focus market, per campaign type per channel, and for partner marketing.
• Registrations come from exactly one conversion action per platform, so mirrored measurements of the same registration are never added up. The footnote lists which actions are counted.
• A channel that is not connected, a registration action that is not found, spend in another currency or an incomplete year is shown as a note, never as a silent zero.

What you get

• See at a glance whether media spend is on track per channel, market and campaign type, and what a registration costs.

What is new

• An event is marked sent only when every channel it was meant for confirmed the delivery. When some channels confirmed and others did not, it is partial; when none did, failed. Before, every processed event was marked sent, even when a platform refused it or did not answer. An event that was not meant for any channel (for example without consent, with no GA4 connected) is marked stored: received and saved, with nothing to deliver.
• The Audit check Conversion delivery now lists, per channel, how many events of the last 7 days were not delivered and why (for example rejected with HTTP 400, no answer, or skipped because a click ID or hashed e-mail was missing).
• A channel that has a conversion destination but is only partly set up (for example a Google tag ID without conversion labels, a conversion step with a Google Ads action for which no conversion label is found, a Meta pixel without an access token or an access token without a pixel, a GA4 API secret without a measurement ID, a LinkedIn conversion ID without a token, or Microsoft Ads or ChatGPT Ads credentials without a conversion step that turns the channel on) now counts as a failed delivery with reason incomplete_configuration and shows in the Audit. Before, such events looked delivered while nothing reached the platform.
• A channel connected only to read campaign data (LinkedIn with only a token or ad account, Google Ads with only a customer ID) is not a delivery destination: it never counts as a failed delivery.
• The delivery results now include delivered: one line per channel (GA4, Google Ads, Meta, LinkedIn, Microsoft Ads, ChatGPT Ads) over all routes and conversion steps, with the outcome and a reason such as http_400, http_429 or timeout. The existing fields in the results stay exactly as they were.

What you get

• Failed deliveries no longer count as delivered, and you can see per channel why a delivery did not go through.

What is new

• For the Google Ads API route (fallback) and offline conversions, the delivery result in the event log is no longer always true. It is true only when Google confirmed the upload, false when Google refused it or did not answer, and not executed: credentials not found when the upload could not run.
• Nothing is switched on by this change: no new uploads are sent to Google Ads accounts.

What you get

• You no longer see offline conversions as delivered when Google never received them.

What is new

• Pulse no longer invents a deduplication key. An event without an event_id is still stored and counted, but is not sent to Meta, LinkedIn, Microsoft Ads or ChatGPT Ads, nor to Google Ads when it also has no order ID. Before, LinkedIn, Microsoft Ads and ChatGPT Ads received a random ID that could never deduplicate with your browser tags.
• New Audit check Events without event ID: shows how many events of the last 7 days had no event ID, and which channels therefore received nothing.
• An empty event_id ("") no longer causes later events with an empty ID to be discarded as duplicates.

What you get

• No silent double counting from made-up IDs, and no silent loss: you see in the Audit when events arrive without an event ID.

What is new

• Pulse now sends Meta exactly the event_id your connector or integration provides, in both Event modes. Before, the Standard mode replaced the event ID of purchases with the bare order number, while the Pulse GTM container sends {{s2s_event_id}}: the two never matched, so Meta could not deduplicate browser and server purchases. An event without an event_id is no longer sent to Meta with a made-up ID; it shows as a failed Meta delivery instead.
• The Meta section of the setup guide, the Event mode explanation in Settings and the developer guide now describe this: tags send {{s2s_event_id}} as eventID for purchases and leads, and the Event mode only changes the event name.

What you get

• Browser and server conversions deduplicate in Meta, so purchases are not counted twice.

What is new

• Orders and form submissions now share a single consent check, and the Respect consent setting is gone: consent comes from the cookie banner signal alone. No signal means no consent — the conversion still reaches Pulse and still counts in your own numbers, but without advertising identifiers or hashed contact data, and it is never forwarded to an advertising platform. The settings page shows a warning when no consent signal has been seen from any visitor in the last 24 hours.

What you get

• Advertising platforms only receive personal data for visitors who actually said yes, and a missing or broken cookie banner is spotted within a day instead of silently costing conversions.

What is new

• The LinkedIn section of the setup guide said LinkedIn offers no read-only reporting access. That was wrong: Pulse reads LinkedIn campaign, creative and demographic analytics and your conversion rules, next to sending conversions server-side. The guide now explains that both use the same LinkedIn access token, and that connecting or reconnecting replaces it.

What you get

• You can see LinkedIn campaign results in Pulse, and you know what to check before reconnecting LinkedIn so conversion tracking keeps working.

What is new

• The timestamp of an event is now read by one rule for Meta, LinkedIn, Microsoft and ChatGPT. The norm is ISO 8601 in UTC (2026-09-16T18:27:46Z). Still accepted: Unix time in seconds and YYYY-MM-DD HH:MM:SS, now always read as UTC. Meta receives Unix seconds, Microsoft and ChatGPT judge their 7-day window on the real event moment, LinkedIn receives milliseconds. A missing or unreadable timestamp falls back to the time of receipt.

What you get

• Delayed events are judged on the moment they happened, with the same reading on each of these platforms; Meta now receives the event time in the format it expects.

What is new

• The developer guide now spells out the consent contract: send consent as a JSON boolean on every event; with false or without the field an event is stored and counted but never forwarded to ad platforms, at most as an anonymous count in GA4. It explains how to see this in the call response and, once live traffic flows, in the Audit (Consent field coverage from 5 events, Consent rate from 10), asks for page_url without query string, and adds a pre-flight to the checklist: two test events (with and without consent) sent before your ad platforms are connected, checked by your Pulse representative on the stored events.

What you get

• A custom integration can check before go-live that the consent field arrives correctly, without test events becoming real conversions: ad platforms are connected only after a successful pre-flight.

What is new

• The Pulse PHP SDK is not currently supported. Custom websites and platforms integrate through the webhook API described in your developer guide; the former SDK guide now points there.

What you get

• One supported integration path for custom websites, documented in your developer guide.

What is new

• The Consent field coverage check in the Audit now names the source when events arrive without a consent field: an outdated connector version (with the current release), a connector that omits the field, or your own API integration. It shows how many events are affected and states that they are stored and counted, but never forwarded to ad platforms.

What you get

• Limited forwarding caused by a missing consent field is visible, with the exact fix, instead of silently costing conversions.

What is new

• The setup guide was reorganised: platform sections and the GTM refinements now collapse so the page stays scannable, a consent card explains which consent signal Pulse needs before anything reaches an ad platform, and three new sections cover Google Search Console (9), reading the dashboard and the trend cards (10), and your account and billing (11). The onboarding checklist now reads as who-does-what, including the measurement-start clamp.

What you get

• Onboarding and day-to-day questions are answered in one place, in the order you meet them.

What is new

• Consent recorded by the Shopify pixel and the Lightspeed thank-you snippet can now only go from yes to no, never back, and an order counts as consented only when every tracking record for it says yes. For Shopify, a yes also needs a record under the checkout or order token; for Lightspeed, a yes only counts when it was recorded after the order was created, with a time zone on the order time. A visitor who first declines and accepts later in the same checkout is treated as not consented.
• Leads sent by the Shopify pixel are treated as not consented for now: they still count in Pulse and reach GA4 as anonymous pings, but no hashed contact data or advertising identifiers are sent. Shopify purchases, which arrive through Shopify’s signed order webhook, are not affected by this lead change.

What you get

• Consent recorded in the browser can no longer be switched back on after a no, a yes recorded before a Lightspeed order was created no longer counts, and a visitor who withdraws consent during checkout stays withdrawn.

What is new

• Pulse now stores and forwards page_url as scheme, host and path only. Query strings, fragments, path parameters and login details are removed before an event is saved and before it is sent to Meta (event_source_url) or OpenAI (source_url). This keeps the WooCommerce order key (?key=wc_order_…) and any personal data in URL parameters away from storage and advertising platforms.

What you get

• Order confirmation links and URL parameters can no longer reach third parties through Pulse.

What is new

• Conversions from visitors who did not give marketing consent still reach the Pulse GA4 property, but only as anonymous pings: event name, value, currency and items reduced to quantity, price and a product ID only when it is a plain product code (no product names, categories or free-text IDs), with a throwaway client ID per hit, consent signals set to denied and personalised ads switched off. No session, user ID, hashed contact data or transaction ID is sent. Conversions with consent are sent as before; csc_consent is now yes for every consented event, including form leads.

What you get

• The Pulse GA4 property keeps showing the full number of conversions and revenue, while conversions without consent carry no visitor, session or user identifiers. Timing and order value remain visible, so within your own shop records such a ping can still be matched to an order.

What is new

• Pulse now reads consent with one strict rule everywhere — platform, SDK, Shopify and Lightspeed alike. Only an explicit yes (true, 1, "yes", "granted") counts as consent; "rejected", "denied", empty, unknown values and objects count as no. When an event carries both consent fields, both must say yes.

What you get

• A consent value that is not a clear yes no longer opens the Google Ads, Meta, LinkedIn, Microsoft or OpenAI delivery.

What is new

• Agencies are now billed through a single Stripe subscription whose quantity follows the number of active client sites, with VAT applied as a Stripe tax rate and the site names listed on every invoice. After checkout, a confirmation page shows the account, the number of sites, the amount and the next invoice date — or a “payment pending” notice while a SEPA Direct Debit is still being processed. The Billing card on the Account page opens the Stripe customer portal for invoices, payment method and billing details.

What you get

• One predictable monthly invoice per agency, itemised by site, with self-service access to invoices and payment details.

What is new

• The Google card now reconciles both worlds in three certainty layers that can never double-count: sent & deduplicated (exact, shared by both bookkeepings), Google adds (view-through, modelled, conversion-time window — constructed on top), and Pulse hint-only (conversions we saw but never sent; it overlaps Google’s modelling, so the larger of the two counts once, never the sum). The crown line compares what each side can individually prove — Pulse’s click-documented conversions against Google’s strict click-attributed count — and a green chip appears only when Pulse exceeds even Google’s fullest estimate. The chip strip has retired in favour of an expandable breakdown that now lives on the Google, Meta and LinkedIn cards alike — each drawing what its platform can honestly split (Google: click-proven / estimated / window; Meta: click and view claims; LinkedIn: a single reported figure) next to Pulse’s sent and hint-only layers, with the individually-proven line as the closing verdict. Closed by default, so the overview stays calm. Each panel now computes its own sent and hint-only figures from that channel’s signal, never borrowing from a neighbouring card. The Google breakdown now compares apples to apples: both layers — click-proven and estimated — sit on the conversion-time calendar, so the confusing window bucket has retired. Every conversion step in Settings can now carry its browser-mirror action, and the channel cards compare against exactly that pair — server action plus web mirror of the non-segment steps only. Segment steps never enter the channel claim, so one lead is never counted twice. Headline claims are status-free: every card reads the all-conversions column on that pair, never Google’s primary flag — the click-proven split appears only as grey context where Google actually exposes it. Channel performance now opens with the number that is Pulse: the uplift hero on each channel card shows how many more conversions the platform measures since Pulse delivers — part direct click recognition, part conversion modelling powered by our deliveries — with recovered conversions and revenue and a weekly trend of claim versus deliveries. A compact GA4 strip on top compares what Pulse measured against the browser property. Every channel card now leads with Proven by Pulse — the real number, split into counted by the action, delivered through our API door, and only in Pulse — while the reconciliation breakdown, the view-modelled context lines and the Server-vs-Web uplift box have retired: their one lasting insight lives on as a single line, the conversions that carried a channel signal but could never be counted for lack of consent. The uplift headline is now budget-fair: it reads conversions per euro, so spend growth can never masquerade as Pulse effect — raw volume and spend change ride along as context. The GA4 strip compares Pulse’s full measurement, unconsented included, against the browser property, and stays silent on percentages below five browser events. The measurement-start clamp now reaches every corner: the all-channels click total, and the campaign table’s truth side — one era, everywhere on the page. The uplift trend now shows on every channel card with enough history: below the volume threshold the line still breathes under an honest “insufficient data” label — no percentage pretends to be a verdict — and freshly delivering channels get a teaser: history plus the delivery-start marker, unlocking the full trend after two complete weeks. The uplift baseline now prefers the same ISO weeks of last year on per-client counterpart actions — seasonality cancels out — falling back to the pre-delivery baseline where last year is too thin, with the basis stated on the card — and a two-pill switcher lets you flip between last year and the pre-delivery baseline instantly, each side keeping its own volume honesty. Delivery start now respects the measurement start (test-week deliveries can no longer wake the trend early), and weeks without meaningful spend — account pauses or missing history — are excluded from every per-euro and spend comparison, on both sides and in the year-over-year basis alike. The measurement-start clamp on delivery start now applies only to a test run-up (a handful of pre-start deliveries); real delivery history keeps its true starting week. And both trend charts gained a dotted running-week tail, so today’s conversions are visible the moment they land — while every percentage keeps judging completed weeks only. The weekly report, Slack and mail digests and the MCP endpoint now read the very same lens: non-segment pairs only, server action plus web mirror, so every surface tells one story. Channel claims are clamped to the measurement start: whatever date range you pick, the claim never reaches back before Pulse was live, so claim and truth always describe the same era — on both sides of the card: the tracked-with-signal figures honour the very same clamp, keeping missed an honest like-for-like number. Below it, Missed compares one-to-one against the strict click-attributed count, and with fewer than ten ad-signal conversions in range the card says insufficient data rather than a confident zero.

What you get

• A zero now means “covered” only when the numbers actually prove it.

What is new

• Three remote kill switches (lead tracking, purchase tracking, script injection) let the platform pause a layer per client instantly while a real fix is prepared. When a strict consent banner deletes pre-consent cookies, the connector now re-reads the landing URL the moment consent is granted — tool-agnostic, with _gcl_aw as a universal Consent Mode beacon — so first-visit click IDs survive without ever storing an identifier before the yes. A new Pulse GA4 Measurement ID setting makes session stitching pick the Pulse property’s cookie when two GA4 properties run side by side. And an opt-in Automatic updates checkbox (default off) hands that choice to the site owner, exactly like WordPress core.

What you get

• An emergency brake per client, sharper first-visit attribution, deterministic stitching, and unattended updates for those who want them.

What is new

• Three remote kill switches (lead tracking, purchase tracking, script injection) let the platform pause a layer per client instantly while a real fix is prepared. When a strict consent banner deletes pre-consent cookies, the connector now re-reads the landing URL the moment consent is granted — tool-agnostic, with _gcl_aw as a universal Consent Mode beacon — so first-visit click IDs survive without ever storing an identifier before the yes. A new Pulse GA4 Measurement ID setting makes session stitching pick the Pulse property’s cookie when two GA4 properties run side by side. And an opt-in Automatic updates checkbox (default off) hands that choice to the site owner, exactly like WordPress core.

What you get

• An emergency brake per client, sharper first-visit attribution, deterministic stitching, and unattended updates for those who want them.

What is new

• The Update URI header now carries the full https URL and the update response includes the id and new_version fields, matching what every WordPress version since 5.8 expects before it shows the update notice.

What you get

• The one-click update bar appears reliably across WordPress versions.

What is new

• The update and calibration endpoints now authenticate through the same hash-aware helper as the event intake, and config signatures use the presented key as the shared secret. One credential, one behaviour, everywhere.

What you get

• The API key from the plugin settings works identically for events, calibration and updates.

What is new

• The form-capture selector is now assembled per builder from the calibration config: Contact Form 7, WPForms and Elementor can each be switched off per client without a release. Defaults keep every builder on, so behaviour without config stays byte-identical; with every builder off, a harmless sentinel keeps the script inert.

What you get

• A misbehaving builder integration can be silenced per client in minutes, straight from the platform.

What is new

• The connector now checks the platform update channel (self-hosted, behind a deliberate publish lock) and fetches its calibration as a signed config: HMAC-verified, re-whitelisted client-side, persisted as last-known-good, with the built-in defaults ruling whenever no config is available. The Elementor form selector is the first calibrated value, and every event reports the active connector_config_version.

What you get

• Calibration fixes reach sites as a config push; future versions install from wp-admin.

What is new

• The platform can now serve connector calibration — selectors, builder flags, segment-field hints, kill switches and feature flags — as a signed JSON document per client (global defaults with per-client overrides). Values are whitelisted server-side: only known sections with the right value types ever leave the endpoint, so the channel carries data, never code. The surface is inert for every current connector; the 1.3 line will fetch, verify and apply it.

What you get

• Calibration fixes become a config push instead of a plugin release.

What is new

• The platform now serves a connector update manifest and a key-gated package download. A deliberate publish lock (the downloads/RELEASE file) controls exactly which version the channel offers — build artefacts can sit ready without any site seeing them. The surface is inert for every current connector; only the upcoming 1.3 line will query it.

What you get

• Future connector releases roll out to shops from wp-admin instead of by hand, one deliberate publish action at a time.

What is new

• The developer guide now documents the field-level deduplication handshake per browser tag (Google Ads Transaction ID, Meta eventID, Microsoft UET event_id), the form_id/form_segment payload fields that drive form- and segment-matched steps, a seconds-vs-milliseconds warning for fbc timestamps (with the intake safety net), guidance for sites running multiple GA4 properties, and a warning that strict consent banners delete unrecognised first-party cookies — the field-level details that decide whether server-side numbers match browser reality. A parity pass against the WordPress connector then added the purchase rule (the shared event ID is the order number, so browser tags keep pairing), the one-line consent rule (send the event, omit every identifier), and the fbp and timestamp payload fields.

What you get

• Server-side implementers hit the pitfalls in the guide instead of in production.

What is new

• The implementation guide gained a Microsoft Ads section (custom-event goals match on the event-name condition, one goal receives browser and server through event-ID dedup), a ChatGPT Ads section (pixel + Conversions API setup, native oppref/obref click-vs-view attribution, the minor-units pitfall and a market-availability note), the three-part GA4 recipe (pageview duplicate for stitching, no lead duplicates, purchase duplicate with transaction ID), the literal AW- prefix warning with the Transaction ID and counting-type guidance for browser mirrors, and new onboarding checklist items: the ?gclid=TEST Consent Mode pre-flight, the auto-tagging check, the consent-banner cookie whitelist, and the test-on-test-pages-then-clean-up ritual.

What you get

• Every onboarding walks past these pitfalls with a checklist instead of a debugger.

What is new

• The server-side Google tag now sends the event ID as the transaction ID for lead conversions (purchases already used the order number). With the browser tag carrying the same s2s_event_id as Transaction ID, Google keeps exactly one conversion whether the browser hit, the server hit, or both arrive.

What you get

• Mirror actions count one conversion per lead, never two.

What is new

• The lead dataLayer push is now idempotent: every event ID fires exactly one s2s_lead push, no matter how often third-party plugins re-trigger form events. Found live: a spam plugin re-broadcast Elementor’s success event, tripling the push and inflating browser mirror tags.
• The Elementor selector matches real forms only (form.elementor-form) — the same spam plugin marks a hidden honeypot input with that class, which previously received its own event ID and push.
• All three fbc builders now use millisecond click timestamps as Meta’s spec requires; second-based values from the id store are lifted automatically. The platform already normalises incoming events, so sites on older connector versions stay covered either way.

What you get

• Browser mirror tags count one conversion per submission regardless of other plugins, and ad-blocked Meta clicks carry their true click time.

What is new

• The Google depth sync now runs a catalogue pass over all enabled conversion actions: freshly created actions (like Pulse mirror actions during onboarding) show up in the action dropdowns immediately, instead of only after their first reported conversion. Existing metric rows are never touched by this pass.

What you get

• Onboarding can map steps to brand-new actions right away. The step editor’s Google action dropdown now reads from this catalogue as well, so freshly created actions are selectable before their first conversion. The catalogue also stores each action’s gtag label, and the step forwarding falls back to it — steps mapped to brand-new actions fire their server-side Google tag from day one instead of silently skipping until the first campaign conversion.

What is new

• The fbclid fallback in connector versions 1.2.18–1.2.22 builds the fbc value with a timestamp in seconds where Meta’s spec requires milliseconds, making those clicks look like 1970 to Meta — pushing real consented conversions out of the click window. The platform now normalises every incoming fbc (10-digit timestamps are lifted to milliseconds) before storing and forwarding, fixing all connector versions in the field at once. Real pixel cookies are untouched. Found on production events during the click-vs-view rollout.

What you get

• Ad-blocked Meta click conversions land in Meta’s click column with their true click time — exactly the conversions Pulse exists to recover.

What is new

• Platform claims now store click-attributed and view-attributed conversions separately where the ad platforms provide the split. Meta delivers 7-day-click and 1-day-view (the windows the sync has always requested; the keys were verified in live responses), LinkedIn delivers post-click and post-view counts (no value split exists on their side), and Google is stored as “split unavailable”: live probes show its attribution event type returns UNKNOWN for GA4-imported and API-uploaded conversion actions.
• The Overview channel cards use the split where it exists (Meta, LinkedIn): missed conversions are computed click-vs-click, the claim line shows click and view attribution separately, and totals stack the view layer on top of the click truth without overlap. Channels without a split keep the previous lower-bound behaviour unchanged.
• The campaign table now also shows Meta claims: campaigns are matched on the campaign ID or name carried in the UTM, compared against the click-window claim per campaign — Meta rows move from “no claim data” to a true click-vs-click gap.
• Microsoft Ads and ChatGPT Ads get their own channel card, shown only when the pixel fields in Settings are filled (UET tag + CAPI token, or Pixel ID + API key): the claims side reads “claims sync pending (API access)” until their reporting APIs are connected, while the Pulse side already counts server-side conversions — for ChatGPT split natively into oppref clicks and obref views.
• The Server-vs-Web section gains Microsoft Ads and ChatGPT Ads sub-cards behind the same pixel gate, using the Meta mechanic: server-attributed events (msclkid, or oppref/obref) compared against the browser beacon on the shared event ID — a pure own-data uplift that works before any reporting API. The Microsoft goal-level comparison (Pulse - Lead vs Browser - Lead) plugs in once Reporting API access lands. Both cards get an event selector (purchase, lead, or any custom event type the site sends) plus a Measure-from date, stored in the same uplift configuration as the other channels. The Meta card gets the same event selector, and its hint now states the click basis explicitly (fbc is only set after a click). The weekly digest headline follows the same rule: click claims where the split exists, with view-attributed conversions noted separately. The Meta and LinkedIn Server-vs-Web sub-cards now follow the same visibility rule as Microsoft and ChatGPT: no setup, no card.

What you get

• Groundwork for click-pure missed-conversion numbers: Pulse clicks compared against click claims, with view-attributed conversions reported as their own line instead of hiding inside the totals.

What is new

• The reviews list keeps its narrow columns on one line: the week-milestone pills, channel, start date and action buttons no longer wrap when a long campaign name squeezes the table — the campaign column is the one that wraps instead.

What you get

• The reviews overview stays readable for clients with long campaign names.

What is new

• The API developer guide (section 4) now documents form_segment — category data conversion steps can match on, with the same rules the WordPress connector applies — and the client guide explains per-service GTM triggers on the same field.

What you get

• Server-to-server integrations can feed per-service conversions too, and GTM setups can mirror them browser-side.

What is new

• Steps have a new optional Segment condition: combined with the connector’s form_segment capture (1.2.21+), one form can now feed different ad-platform actions per chosen service — “Roof” to the Roof action, “Facade” to the Facade action. An empty segment matches everything, so every existing step behaves exactly as before.

What you get

• Per-service conversions from a single form, configured with one extra field on the step.

What is new

• The Elementor form handler read submissions through a method that does not exist in Elementor’s Record API (get_fields() instead of get("fields")), so the fields array was always empty: email and phone — and with them the full hash set — and the new form_segment were never populated on Elementor leads. The handler now uses the canonical API with the old call as fallback. Found by the 1.2.21 segment test on a production form.

What you get

• Elementor leads finally match on Google, Meta, Microsoft Ads and ChatGPT Ads via hashed email/phone, and segment capture works end to end.

What is new

• New opt-in setting Form segment: with the checkbox on, the choice field with field ID type on Elementor forms travels as form_segment on the lead event and in the dataLayer push — so one form can feed per-service conversions (“Roof”, “Facade”) and per-service GTM triggers. Off by default; free-text values containing an @ are refused and values are capped at 120 characters.
• CookieScript consent detection now lets the categories decide instead of the accept button: CookieScript writes action: "accept" even when a visitor unticks the targeting category, which the old shortcut treated as consent. Found by an empirical partial-consent test.

What you get

• Per-service lead measurement without touching the form, and visitors who explicitly decline marketing are never treated as consented.

What is new

• The API guide now documents form_id/form_name on lead events (conversion steps match on the token) and the ChatGPT pixel’s __oppref cookie as a click-capture fallback — and the client guide explains per-form browser mirror tags in GTM.

What you get

• API integrations get per-form reporting, and every capture fallback the connector uses is documented for server-to-server integrations too.

What is new

• Lead events now use the same vendor-cookie safety nets as orders: when a CDN strips the connector’s own cookies, the Microsoft UET cookie (_uetmsclkid) and the ChatGPT pixel cookie (__oppref) still deliver the click ID — caught by the 1.2.19 production test before any external install existed.

What you get

• Lead-driven sites behind aggressive CDN caching keep their Microsoft Ads and ChatGPT Ads click attribution.

What is new

• The s2s_lead dataLayer push now carries a form_id token (elt-…, wpf-…, cf7-…) identical to the server event — for every supported form plugin — so GTM can fire a browser mirror tag per individual form.
• ChatGPT view-through: the pixel’s __obref cookie now travels as obref on orders and leads (consent-gated, exactly like _fbp), and its __oppref cookie is a new click-capture fallback.

What you get

• Per-form browser-vs-server comparison becomes possible, and ChatGPT Ads can attribute view-through conversions once the pixel runs via the GTM container.

What is new

• The Lightspeed and Shopify modules now send the same per-platform hash set as the WordPress connector — email_hash (Google, with the Gmail dot rule), email_hash_ms (Microsoft), email_hash_oai (ChatGPT), phone_hash (E.164 with plus) and phone_hash_oai — built with one shared normalisation library, verified against the ad platforms’ official test vectors.

What you get

• Lightspeed and Shopify shops match on Microsoft Ads and ChatGPT Ads with the same quality as WordPress shops — and Google matching improves through proper Gmail and E.164 normalisation.

What is new

• The API developer guide (sections 4, 5, 7 and 8) now documents the complete per-platform hash set — email_hash, email_hash_ms, email_hash_oai, phone_hash, phone_hash_oai — with each platform’s exact normalisation, plus the ChatGPT Ads click reference oppref throughout: capture, pulse_ids, channel_hints and the consent rules.

What you get

• Server-to-server integrations reach the same match quality on Microsoft Ads and ChatGPT Ads as the WordPress connector.

What is new

• Clients can now be registered as plain WordPress sites (forms and leads, no shop) — the connector already supported them, the platform label now says so too.

What you get

• Lead-driven WordPress sites are labelled correctly instead of as WooCommerce.

What is new

• Clients can now be grouped under an agency. Agency users automatically see every client of their agency — including clients added later — and switch between them with the client picker in the top bar, without separate logins.

What you get

• One login for the whole portfolio: an agency manages all its clients from a single account, and new clients appear automatically.

What is new

• The Pulse GTM container now ships six extra tags on the familiar base-plus-conversion pattern: a Microsoft UET base tag with purchase and lead events, and the ChatGPT pixel with order and lead events — all deduplicated against the server through the shared s2s_event_id, with ChatGPT amounts converted to minor units automatically.
• Two new container variables — Microsoft UET Tag ID and ChatGPT Pixel ID — switch the channels on; unused variables are harmless. The guide (section 1) covers the import, a new double-counting check and an optional All Pages setting for maximum view-through.

What you get

• Browser and server side by side on Microsoft Ads and ChatGPT Ads as well — view-through attribution runs via the browser tags, and both sides deduplicate through the shared event ID.

What is new

• New onboarding check: Pulse sends one synthetic event through the real forwarding code per configured channel — validate-only for ChatGPT Ads (nothing is stored) and a goal-neutral pulse_preflight event for Microsoft Ads that matches no conversion goal — proving the token, tag/pixel ID and every field format end to end before a conversion step goes live.
• The verdict appears on the Audits page as Forwarding pre-flight per channel, including field warnings such as InvalidSha256, so “does it work?” is a green line instead of a hope.

What you get

• Every new channel is proven working at onboarding — wrong tokens, wrong IDs or malformed fields surface before the first real conversion, not weeks later.

What is new

• Hashing now follows each ad platform’s own normalisation: the connector sends a full hash set (Google, Microsoft and ChatGPT variants for email; E.164 and digits-only variants for phone), verified against the platforms’ official test vectors at build time. Empty values no longer produce a hash.
• The oppref click reference from ChatGPT Ads is captured on landing and stored for 400 days alongside the other click IDs (consent-gated), so ChatGPT conversions can be matched server-side. Lead events now also carry msclkid and oppref.
• The click touch in pulse_ids now stores its campaign: when a later plain visit wipes the last-touch UTM layer, the campaign is restored from the click itself — no more attributable orders without a campaign.

What you get

• Higher match rates on every channel, ChatGPT Ads ready on the site side, and campaign attribution that survives return visits.

What is new

• Conversion steps can now forward to Microsoft Ads (Conversions API, matched on msclkid plus hashed email/phone) and ChatGPT Ads (OpenAI Conversions API, matched on the oppref click reference plus hashed email/phone). Configure the UET tag/token and Pixel ID/key on the Settings page, then enable the channel per conversion step. Only consented events are sent, deduplicated against any browser tag through the shared event ID.

What you get

• Two more ad platforms receive your server-side conversions — same consent gating, same step model, no extra site changes.

What is new

• Clients can now be set up as B2C (lead-driven consumer businesses such as contractors and installers). B2C accounts get the same lead-centric reporting, reviews and step templates as B2B; the type is shown separately so benchmarks can diverge later.

What you get

• Lead-driven B2C businesses are reported the way they work: forms and quote requests first, no revenue placeholders.

What is new

• The Audit now includes Google click validation: every day Pulse asks Google, per order, whether the stored click of each consented conversion is recognised and within the attribution window. Nothing is uploaded — it is a validate-only request — and the result reads like “36 of 36 clicks confirmed (100%)”. Pulse creates a small helper conversion action named Pulse click check in your Google Ads account for this; it never receives conversions.
• New Audit check Forwarding configuration: it flags accounts without active conversion steps, since steps drive claim data per action, campaign reporting and the weekly S2S-vs-browser check.
• The Missed ad conversions by campaign card now lists only conversions with a stored ad click (Google, Meta, LinkedIn, Microsoft or a paid medium); organic, business-profile, referral and newsletter traffic is excluded, and campaigns whose channel has no per-campaign claim are labelled as such.

What you get

• Order-level proof from Google itself that your clicks are captured correctly — and a campaign table that only counts what advertising actually drove.

What is new

• Channel cards now tell the full story in one row: claimed conversions and revenue (your mapped S2S action, reported by conversion date), Claimed ROAS, missed conversions and revenue (Pulse’s click-based count minus the claim — a lower bound, with the no-consent share shown inside), totals, Real ROAS and the ROAS adjustment: how much higher your true return is than what the platform reports, so you can set bidding targets accordingly.
• The by-campaign card uses the same truth-minus-claim definition on the same conversion-date axis.
• Channel cards are now split in two rows — Claimed by the platform on top, What Pulse adds below — and missed conversions are broken down into missed purchases and missed leads.

What you get

• One consistent framework from cost to real return — directly usable for reporting and for setting platform ROAS targets.

What is new

• “Missed” now means exactly that: the conversions Pulse counted without marketing consent, minus the share the platform already covers through modeled conversions on your mapped S2S action. The by-campaign card shows claimed vs missed per campaign (with a “covered by modeling” mark where the platform’s estimates already account for everything), and the channel cards’ totals are claimed + missed — overlap-free by construction.

What you get

• The gap you see is the gap that is real — no double counting between your recovered conversions and the platform’s own estimates.

What is new

• Server-side Google Ads conversion pings now carry the Consent Mode granted signal (gcs). Server conversions are consent-gated by design, so the signal states what was already true — and keeps the conversion action fully eligible for Google’s conversion modeling alongside your browser tags.

What you get

• Consistent consent signalling across browser and server pings protects modeled-conversion coverage on server-enhanced actions.

What is new

• The Shopify integration now installs like an app should: one click, and the web pixel activates automatically. It captures the same signal set as the WordPress connector — channel and campaign category before any consent choice, and click IDs plus the multi-touch store only with marketing consent.
• Shopify stores now feed the missed-conversions cards and the cookie-extender drill-down, just like WordPress shops.

What you get

• Shopify merchants get the complete Pulse picture — consented, missed and long-window — without any theme or code changes.

What is new

• The click-age buckets on the Overview are now clickable: each opens a breakdown of its conversions per ad channel and campaign, with conversion counts and revenue — so you can see exactly which campaigns the extended attribution window recovers.

What you get

• The > 90-day bucket is no longer just a number: it names the campaigns no ad platform can still credit.

What is new

• New Technical SEO tab on the SEO page, next to Focus pages: your site’s Ahrefs Site Audit health score with trend, plus the full error, warning and notice lists — every issue with a plain-language explanation and its week-over-week change.
• Error and warning issues are clickable: each expands to show the affected URLs (top 100 by organic traffic, with HTTP status), refreshed weekly.

What you get

• Technical SEO regressions surface right next to your organic performance — without leaving Pulse.

What is new

• Saving a setting no longer jumps the page back to the top: every form on the platform now restores your scroll position after saving — change five settings in a row without scrolling back down once.

What is new

• The webhook developer guide now documents pulse_ids (the first/last-touch store that powers multi-touch and long-window attribution — with an effectively unlimited window for server-side integrations), phone_hash for better match quality, the rate limit (120 events/min with safe retries), and an explicit warning to capture channel and campaign fields before any consent flow.

What you get

• Custom and SaaS integrations built from the guide now get the full Pulse feature set from day one.

What is new

• New audit check Consent-capture parity: the channel-signal rate of consent-declining conversions is compared against consenting ones. A large gap means the cookie banner or CDN is silently blocking pre-consent capture — exactly what the 1.2.16/1.2.17 connector releases fix.
• The audit now flags shops running an outdated connector, using the version telemetry every event carries.
• New SEO category: Search Console sync freshness, keyword→conversion matcher output and the GA4 organic landing data it depends on — all volume-aware, so low-traffic sites are marked "not applicable" instead of failing.

What you get

• Tracking gaps and stale SEO data surface in the Health Score before they quietly distort a week of reporting.

What is new

• Some consent banners actively delete unrecognised cookies after a visitor declines. The landing-capture data (channel category and UTM campaign fields, never identifiers) now also travels through browser storage and is handed over at submit time — with the order at checkout and with every lead form.

What you get

• Channel and campaign attribution for consent-declining visitors now works on every shop, including the strictest cookie banners.

What is new

• A tiny first-party snippet records the ad channel (category only) and the UTM campaign fields at landing — before any consent tool, ad blocker or CDN cache can get in the way. No identifiers are ever stored without consent.
• Leads now carry the same channel and campaign signal as orders, and all marketing identifiers on leads are gated on consent (parity with the order path).

What you get

• Missed conversions keep their channel and campaign, so your dashboards show the true size of what standard tracking loses — on every shop, whatever cookie banner it runs.

What is new

• Campaign reviews: standardised check-ins for new or changed campaigns at week 2, 4, 6 and 8 — the last two weeks, the total so far and the change versus the two weeks before, judged against benchmarks with a one-line verdict and a creative-by-creative comparison. New campaigns are picked up automatically; add any campaign manually (e.g. after a budget or creative change).
• Focus pages (SEO → Focus pages): your best Google Ads search terms compared with their organic presence. Terms you pay for but do not rank for become your focus-page list, with a potential score, the currently ranking page and an editable label (generic / competitor / brand).
• Video retention and carousel depth on the Weekly: quartile retention and completion per video (Meta and LinkedIn), swipe depth and card CTR for LinkedIn carousels, auto-play depth for Meta carousels — each against a benchmark for its own channel and format.
• Awareness benchmarks: awareness campaigns are now judged against awareness benchmarks (lower CTR expectations than performance), adjustable per client. Hover any complex column header for its definition.
• SEO page reorganised into Overview, Keywords → conversions and Focus pages.

What you get

• Know within two weeks whether a new campaign works, see which creative carries it, and turn your paid search data into an SEO roadmap.

What is new

• Search Console data is pre-aggregated daily, so the SEO and Weekly pages stay instant even with millions of rows of history.
• Heavy background work (historical backfills, keyword matching) now runs through a single low-priority queue, one job at a time, so it never competes with the dashboards.
• Automatic guarding: slow queries are reported daily and long-running requests are cut off so one heavy page can never block others.

What you get

• More data, more clients, same speed — by design rather than by luck.

What is new

• New SEO page: organic clicks, impressions, CTR and average position from Google Search Console — trend chart, top queries, top landing pages, device and country splits, with a period picker and up to 16 months of history.
• The Keyword Matcher now lives inside Pulse: Search Console keywords are matched to your GA4 organic conversions per landing page (date + page + device + country, with fallbacks) and conversions are attributed by position-weighted click share — so you see which keywords actually convert, not just which ones get clicks.
• Conversions follow your conversion-step mapping (purchases for shops, registrations and trials for SaaS), the same definition used everywhere else in Pulse. A match-quality panel shows how solid the attribution is.
• The Weekly gets an SEO section: organic KPIs week-over-week, keyword risers and fallers, and attributed organic conversions.

What you get

• Search Console tells you what people search; GA4 tells you what converts. Pulse now connects the two — per keyword, per landing page, daily, with history.

What is new

• Restores the UTM campaign capture (source/medium/campaign/content/term) that was unintentionally missing from 1.2.14 — the 400-day first-party UTM cookie and its Order Attribution fallback are back in every event.
• The connector now reports its version with each event, so Pulse can show which version each shop runs.

What you get

• Campaign attribution for missed conversions works again as it did in 1.2.13; the platform can flag outdated connectors automatically.

What is new

• The Meta and LinkedIn syncs now store the real ad format per creative (Carousel, Video, Image, Single image, Document …).
• The Awareness creatives table on the Weekly judges each creative against a benchmark for its own channel and format, and every table column is click-to-sort.

What you get

• A carousel is no longer measured against a video benchmark — above or below the line finally means something per format.

What is new

• The campaign table now splits into Performance, Branded and Awareness — grouped automatically by campaign naming, each with its own subtotal.
• The Awareness section reports reach metrics: impressions and CTR against a per-platform benchmark (adjustable per client), with a clear above/below indicator.

What you get

• Judge every funnel layer on the metrics that fit it — conversions for performance, visibility for awareness.

What is new

• Compatibility verified and tested up to WordPress 7.1 (release August 19).

What you get

• Update WordPress on day one without waiting for the plugin.

What is new

• New optional Cookie domain setting: set it to .example.com to share Pulse cookies across subdomains. Empty keeps the current host-only behaviour.
• Fresh installs now default to the pulse.tj-da.com endpoint.

What you get

• Shops with a separate app or checkout subdomain keep full attribution across hosts.

What is new

• Every Monday morning Pulse can post a weekly report to your Slack: spend, clicks and claimed conversions per channel, the conversion funnel, campaign highlights (top spend, risers, drops, new and stopped campaigns) and concrete action points.
• Google campaign lines show primary and secondary conversions separately.

What you get

• Your week in one glance, in the channel where your team already works — no login needed.

What is new

• The campaign table on the Weekly page has an extra All conv. column: Google campaigns show conversions including secondary actions, next to the primary number.

What you get

• The same primary-versus-all split you know from the Google Ads interface, now in Pulse.

What is new

• New API route: send event_type: "offline_conversion" for phone orders, CRM deals or in-store sales.
• No click ID at hand? Pulse recovers the Google click from the customer’s history via email_hash (up to 90 days back).
• Supports conversion_time so the conversion lands on the day it actually happened.

What you get

• Sales that never touched your website finally count in Google Ads — attributed to the ad click that caused them.

What is new

• Conversion steps now drive Google Ads forwarding directly: the action you pick per step is the action that gets the conversion, via the gtag route with automatically synced labels.
• Account-level settings remain as fallback for unmapped events.

What you get

• Every mapped step reports to its own Google Ads conversion action — deduplication with your website tag stays intact.

What is new

• Per-action conversion data is now synced for Google Ads, LinkedIn and Meta.
• The Weekly page compares, per conversion step and per platform, what the ad platform claims against what Pulse measured server-side — including the fair channel-signal denominator.
• Two new analysis endpoints on the Pulse MCP connector expose the same data to AI assistants.

What you get

• See exactly where platforms over-claim — per conversion, per channel, with the same definition on both sides.

What is new

• New Weekly page: ISO-week view with week-over-week KPIs for spend, clicks, claimed and server-side conversions.
• Channel table, conversion funnel and a campaign table with deltas per campaign.

What you get

• One page that answers “how was last week” — the same definitions the Slack report uses.

What is new

• Updated DPA: channel hints and UTM parameters documented as always-processed measurement data (legitimate interest, no personal identifiers); click IDs and Pulse IDs remain strictly consent-based.
• Signing in now lands on the Overview instead of Settings.

What you get

• The legal paperwork matches exactly what the software does — ready for your privacy officer.

What is new

• Every event now carries privacy-friendly channel hints (which ad platform touched this visitor) and UTM campaign parameters — also without marketing consent, since no personal identifiers are involved.

What you get

• Conversions without consent become measurable and attributable per campaign instead of disappearing entirely.

What is new

• Cookie extender card: how old the attribution data behind your conversions is — including the >90 days bucket that only exists thanks to Pulse.
• Missed conversions per campaign (no consent, campaign known via UTM) and an anonymous-visitors bucket.

What you get

• See in numbers what Pulse recovers that browser tracking structurally loses.

What is new

• Attribution cookies are now set through three layers (server cookie, vendor JavaScript, fallback) so aggressive CDN caching — such as Cloudflare cache-everything — can no longer strip them.
• Cookie lifetime extended to 400 days (the browser maximum).

What you get

• Attribution survives CDN setups and returns customers up to 13 months later still get credited to the original ad click.

What is new

• Browser-fired uplift events are registered separately from server events; every KPI, funnel and list strictly counts server-side data.

What you get

• Dashboards can never be inflated by browser tags — the server-versus-web uplift becomes measurable instead.

What is new

• Per-client implementation guide, generated from your configured conversion steps: authentication, payload reference, click-ID persistence and a full example per event.

What you get

• Your developers integrate in hours, not days — with a guide that always matches your setup.

What is new

• Upgrade references now point to TJDA Pulse (pulse.tj-da.com); legacy Pro-plugin notice removed.

What you get

• One clear upgrade path from the free plugin to the full platform.

What is new

• Form tracking for Contact Form 7, WPForms, Gravity Forms and Elementor Pro Forms.
• Session ID tracking for correct channel attribution in GA4 — conversions land on Google Ads, Meta or Organic instead of Unassigned.
• Support for all 10 major cookie consent tools, a debug log viewer, and richer purchase payloads (items, shipping, tax).

What you get

• Lead tracking on any form stack, with attribution that survives payment redirects.

What is new

• Daily GA4 sync (sessions, events, channels, countries, devices) next to the ad-platform data.
• Overview dashboard with conversion funnel and KPIs; health dashboard for monitoring.

What you get

• Analytics and ads side by side, verified against what your server actually measured.

What is new

• First public release: GA4 server-side purchase tracking via the Measurement Protocol.

What you get

• Server-side measurement for every WooCommerce shop — free, from the official plugin directory.

What is new

• Server-side event pipeline: webhook in, forwarding out to GA4, Google Ads, Meta and LinkedIn.
• Daily ad-platform sync (spend, clicks, conversions, search terms) as the claim layer.
• WooCommerce connector, consent-aware by design.

What you get

• The foundation: conversions measured where they cannot be blocked — on the server.

What is new

• License portal live for the paid S2S plugin; client onboarding begins — the first shops connect in the same weeks.
• The multi-shop connector line (1.2.x) starts rolling out.

What you get

• From a single custom build to a product multiple shops run in production.

What is new

• First server-side conversion measured with the custom-built predecessor plugin — direct per-shop forwarding to Google and GA4, the approach that became TJDA Pulse.

What you get

• Every feature above stands on this idea: measure conversions where they cannot be blocked.