Changelog

What is new

• The get_recent_events tool of the Pulse MCP connector no longer returns the order number of an event. The other fields stay: time, event type, value, currency, consent status, source, form and the per-channel delivery results.

What you get

• Order numbers no longer reach an AI assistant or its conversation history.

What is new

• The “Keywords” item is removed from the Analyze menu. It opened the separate Keyword Matcher tool in a new tab; Pulse no longer links to that tool.
• Keyword conversions are in Pulse itself, under SEO → Keywords → conversions: Search Console keywords matched to your GA4 organic conversions.

What you get

• The Analyze menu no longer points to a page that is not available, and keyword conversions have one place: the SEO page.

What is new

• When part of the weekly mail or the Slack digest could not be loaded, the report shows “—” instead of a number for every figure from that part, and a line “Section … unavailable this week (data error) — figures may be incomplete” that names the part. This includes the count of conversions without consent: the line “No consent, ad-click signal” in the weekly mail then shows “—”, and the Slack digest shows “Signals” with “—”.
• If ad spend and clicks, or the Pulse truth counts (purchases and leads), could not be loaded, no weekly mail or Slack digest is sent for that week, and TJDA is notified.
• Correction to the note “Weekly report: the no-consent count follows the delivery consent rule” (2026-10-15). It said that if the count cannot be read, the weekly mail and the Slack digest say “not available”, and that the same goes for the Pulse truth figures and the truth per funnel step in the mail and in the Slack digest. In the weekly mail and the Slack digest this is now “—” with the line above, and if the Pulse truth counts cannot be loaded, no report is sent for that week instead of a report that says “not available”. The weekly page in Pulse still says “not available (data error)”. That note also said that the weekly mail always shows the line “No consent, ad-click signal” next to “Pulse truth”: it shows that line (also when the count is 0) whenever the mail shows Pulse truth, that is, once Pulse has received server-side events for the account. The old note stays as it was published.

What you get

• A part of the weekly mail or the Slack digest that could not be loaded can no longer look like a zero, and the note of 2026-10-15 is corrected where the mail and the Slack digest now work differently.

What is new

• The Audit (Connector health) now explains a new notice of connector 1.4.0, which is not yet released: a visitor's click cookie was full, the connector left out extra click IDs that TJDA switched on, and because the newest remaining click was older than the cookie lifetime, it did not rewrite the cookie. The visitor's existing click cookie stayed as it was, so nothing from that visit, such as a new extra click ID, was kept in the click cookie. In connector 1.4.0 the notice that extra click IDs were left out now only appears when the connector did rewrite the cookie. Released connector versions do not report either.

What you get

• You can see when a new extra click ID was not kept, instead of a notice that suggests the cookie was rewritten without it.

What is new

• The Audit (Connector health) now explains a new notice of connector 1.4.0, which is not yet released: when a visitor withdrew marketing consent, the connector did not add its small script that removes its own copies from the browser's local storage, because the page could not be shown to be excluded from caching, or because the response had no page to add it to. Released connector versions do not report this.

What you get

• You can see when the cleanup in the browser after a withdrawal did not run on that page, instead of finding an unexplained gap.

What is new

• The Audit (Connector health) now explains three new notices of connector 1.4.0, which is not yet released: a connector update was not installed because it needs a newer PHP version or a newer WordPress version than the site runs, or because that requirement or the version of the site could not be read. Connector 1.4.0 only holds such an update back; this check never installs anything. Released connector versions do not report this.

What you get

• You can see why a site stays on its current connector version, instead of finding an unexplained gap.

What is new

• The Audit (Connector health) now shows how many notices a shortened daily report from the connector left out, separately for information notices and other notices. Connector 1.4.0, which is not yet released, shortens a daily report that is too large by leaving out information notices first, and always says that it shortened the report. A fixed list of notices that a security check or a measurement relies on is never left out; this list also includes the notices about privacy decisions (the Data Processing Agreement check that keeps new features off, and the withdrawal of consent). If notices other than information notices are left out, the Audit shows that as a problem, because the status may then be incomplete.
• The Audit also mentions a site whose latest daily report carried no notices while the report before it did: usually nothing new happened, but it can also mean that notices were left out.

What you get

• When the connector has to shorten its daily report, you can see that notices were left out and how many, instead of finding them silently missing.

What is new

• The Audit (Connector health) now explains a new notice of connector 1.4.0, which is not yet released: a lead with consent came from a form in which the connector found no email field, or no phone field, of the right type (or could not read the form's fields). Connector 1.4.0 reads the email address and phone number of a lead only from a field of that type, so such a lead carries no hashed email address or phone number. The notice names the form builder (Contact Form 7, Gravity Forms, WPForms or Elementor) and whether the email or the phone field was missing.

What you get

• When leads from a form arrive without a hashed email address or phone number, you can see in the Audit that a form of that form builder has no field of that type, or that the connector could not read its fields, instead of finding an unexplained gap. The notice is a signal, not a count of leads: the connector notes it at most once every five minutes per site.

What is new

• Pulse now knows eight more ad click IDs that connector 1.4.0, which is not yet released, can keep: TikTok (ttclid), X (twclid), Snapchat (ScCid), Pinterest (epik), Reddit (rdt_cid), Google Campaign Manager 360 / Display & Video 360 (dclid), Yandex Direct (yclid) and impact.com (irclickid or im_ref). Each is off. TJDA can switch one on for a single account only when a purpose has been decided for that click ID and the account accepted a version of the Data Processing Agreement with a rule for it; today that is not possible for any of them. When one is switched on, the connector keeps only the latest click for it, without a campaign, only for visitors with marketing consent, in its consent-based click cookie, and sends it to Pulse with the conversion. Pulse does not send these click IDs to TikTok, X, Snapchat, Pinterest, Reddit, Google Campaign Manager, Yandex or impact.com. If that cookie is full, the connector leaves out extra click IDs in a fixed order; the click IDs of Google, Meta, LinkedIn, Microsoft and ChatGPT are never left out for this. The Audit card Remote switches set by TJDA lists any that are on.
• The Audit (Connector health) also explains two new notices of connector 1.4.0: an extra click ID that was switched on arrived in a form the connector does not accept, so it was not stored; and extra click IDs were left out because a visitor's click cookie was full.

What you get

• A click ID is never collected without a decided purpose and a rule in your Data Processing Agreement; once both are in place, no connector update is needed.

What is new

• The Audit now has a card Remote switches set by TJDA. It lists each switch in the connector's remote configuration that TJDA turned off, for your account or for all accounts. For each form builder it shows both settings, the lead script in the browser and the server hook, and where each one that is off was set.
• The Audit (Connector health) now explains three new notices of connector 1.4.0, which is not yet released: a form lead that was not sent because TJDA switched off the connector's server hook for that form builder; a Gravity Forms lead without the browser push on its confirmation page because TJDA switched that push off; and consent read as "no" because TJDA switched off the reading of a consent banner. If TJDA switches off the daily connector health report, the Audit says so instead of warning that no report arrived.

What you get

• You can see when TJDA switched part of the connector off, instead of finding an unexplained gap.

What is new

• The Audit has a new line, Value basis match — Google Ads. When a browser (web) action is linked to your purchase step, Pulse compares, for each day of the last 90 days (up to yesterday) that has both Pulse purchases (with consent and a Google signal) and conversions of that action, the Google Ads average conversion value with the average Pulse order value on each of the three value bases: incl. VAT, excl. VAT, and excl. VAT and shipping (the last one for orders from the WooCommerce connector only). If the values clearly fit another basis than the one set in Settings for Google Ads (at least 10 days, and the middle half of the ratios within 3% of 1.00), the line shows a warning that names that basis.
• With fewer than 10 comparable days, when no browser (web) action is linked to your purchase step, or when no basis fits clearly, the line says that Pulse cannot tell (n/a) and why. Pulse never changes the setting for you and never recalculates anything because of this line: the choice stays yours. It is an indication from daily averages, not a match per order, because Google Ads counts conversions on its own day and may include modelled ones.

What you get

• If Google Ads counts your conversion values excl. VAT while Pulse compares incl. VAT, you now get a visible hint instead of a card that quietly compares two different things.

What is new

• The Audit (Connector health) now explains a new notice of connector 1.4.0, which is not yet released: a visitor's ad click ID was too large for the connector's cookie for that click: either too large for the browser to accept, and an earlier click cookie of that visitor, if any, stays in place; or too large to keep for longer after the visitor gave consent, so the connector left it as it was (normally a session cookie). The connector never shortens a click ID. Released connector versions give no notice for this.

What you get

• You can see when a visitor's ad click could not be kept, instead of finding an unexplained gap.

What is new

• The Audit (Connector health) now explains a new notice of connector 1.4.0, which is not yet released: a checkout request arrived inside a batch request of the WooCommerce Store API, or could not be ruled out because the batch was too large to inspect fully. The connector does not read its Click ID mirror from a batch, so an order placed this way carries no ad click from the mirror. The connector's own click cookie, if present, is used as before. Released connector versions do not report this.

What you get

• You can see when an order could not get its ad click from the mirror, instead of finding an unexplained gap.

What is new

• The Audit (Connector health) now explains a new notice of connector 1.4.0, which is not yet released: after a visitor gave consent, one of the connector's own cookies with the channel or campaign details of a visit was too large to keep for longer, so the connector left it as it was (normally a session cookie). Released connector versions skip such a cookie without a notice.

What you get

• You can see when the channel or campaign details of a visitor could not be kept, instead of finding an unexplained gap.

What is new

• TJDA can now place an account in a pilot phase for connector updates. The sites of such an account that run connector 1.4.0 or later (for connector 1.4.0, not yet released) can then be offered a new connector release before other sites. All other accounts keep getting the general release, as before.
• Sites with a connector older than 1.4.0 always get the general release.

What you get

• A new connector release can first run on a few sites before it is offered to every site.

What is new

• When the connector reports that it sends its API key to Pulse without certificate verification, the notice in Connector health now also says that TJDA replaces the API key of this account after the setting on the site that turns verification off has been removed.
• Nothing else changes: the same status, and nothing in what Pulse stores or forwards.

What you get

• You know what happens after the setting is removed: the API key that may have been sent without certificate verification is replaced.

What is new

• When Pulse refuses a connector update download with your connector key, for example for a version that is no longer offered or a package that is missing, the Audit now shows Update downloads refused: how many downloads were refused per day and why, for the last 30 days. Every refused download now gets the same answer from Pulse; WordPress shows "Download failed", as before.

What you get

• A site that did not install an offered connector update no longer fails without a trace: you see it in the Audit.

What is new

• When the latest events of this account come from connector 1.3.x, the Audit check Connector up to date now adds that this connector version installs updates from Pulse without checking a signature. The check looks at the connector version of the most recent event of this account, not at every site that uses the same key. The status of the check does not change.

What you get

• You can see when this account still runs a connector that installs updates without a signature check.

What is new

• The Audit (Connector health) now explains a new notice of connector 1.4.0, which is not yet released: a lead with consent came from a form with different values in two or more email fields, or in two or more phone fields. Connector 1.4.0 then leaves the hashed email address or phone number for that field type out of that lead, because it cannot tell which value belongs to the visitor.

What you get

• When such a lead arrives without a hashed email address or phone number, you can see why in the Audit instead of finding an unexplained gap.

What is new

• For a site where the consent banner set in the connector is iubenda and the connector is 1.4.0 or later (for connector 1.4.0, not yet released), Connector health in the Audit now carries a note. In a test on a test shop, iubenda turned the connector's click ID script into a blocked script on a page where the visitor had made no consent choice, in 5 of 5 runs. Click IDs in the web address of a visitor who consents later may therefore not come from that script.
• The note does not change the status of the line, and it changes nothing in what Pulse stores or forwards. Whether and when iubenda runs the script after consent, and how many click IDs this costs, has not been measured.

What you get

• You can see that, with iubenda, part of the connector's click ID capture may not run, instead of finding an unexplained gap.

What is new

• In New features per site, when a feature is switched on at a site and covered by the Data Processing Agreement, but the connector keeps it off there, the Audit now names the reason the connector reports: switched off by TJDA, Landing capture is off at the site (for the Click ID mirror), no current Pulse configuration at the site yet, or an older Data Processing Agreement status at the site. This needs connector 1.4.0, which is not yet released; for an older report the Audit keeps the general explanation.
• If the two latest reports of a site, on two different days and at least 20 hours apart, both say that the connector has no current Pulse configuration, the line becomes a warning. A reason the Audit does not recognise is also shown as a warning.
• The Audit also explains a new notice of connector 1.4.0: a visitor's ad clicks that did not fit in the connector's click cookie, so they were not stored.
• It also explains a second new notice of connector 1.4.0: the Click ID mirror held an ad click older than the 90-day measurement window, so the mirror's copy of that click was not used. This window applies only to the mirror: the connector's own click cookie, if present, is used as before.

What you get

• You see why a feature you switched on is not active, and a site that keeps waiting for its configuration does not go unnoticed.

What is new

• The Audit now explains one more notice that connector 1.4.0 can report (for connector 1.4.0, not yet released): a Gravity Forms lead that was marked as having its event ID in the browser push on the confirmation page, while the connector did not print that push. Such a lead is not deduplicated against the browser tag.
• The explanation of the notice about a form listener that was not registered when a form was submitted now also names Gravity Forms, and the line about Gravity Forms leads in Connector health says that it does not apply to leads for which such a notice was reported.

What you get

• When a Gravity Forms lead does not get its browser push after all, you see it in the Audit instead of an unexplained gap.

What is new

• When the current version of the Data Processing Agreement covers new connector features, only a user of the client itself can accept it. An agency user is then no longer sent to Settings after logging in, but to the Overview. The Data Processing Agreement card in Settings still says that the client itself has not yet accepted it.
• No version of the agreement covers new connector features yet, so for now nothing changes after logging in.

What you get

• Agency users are not sent to a page where they cannot do anything about the agreement.

What is new

• The Audit now explains one more notice that connector 1.4.0 can report about connector updates that were not installed (for connector 1.4.0, not yet released): an update that another plugin or code on the site stopped before the download (for example an update lock or a maintenance plugin). The connector respects that refusal, so nothing is installed in that case.

What you get

• A site that stays on an older connector because something on the site holds back its updates is visible in the Audit.

What is new

• The weekly report by e-mail is now sent to each recipient as a separate e-mail, with only their own address in the "To" field. Recipients no longer see each other's e-mail addresses, also when the recipients include @users.
• An address that appears more than once (also with different capital letters) receives the report once. If the report cannot be delivered to one recipient, the other recipients still receive it. The content of the report does not change.

What you get

• The e-mail addresses of your colleagues and of your agency are no longer shared with everyone who receives the report.

What is new

• A user who does not belong to an agency now sees and manages only the clients that are linked to their account. In an edge case, such a user could also reach a client without an agency link that was not linked to their account; that access has been removed, so the list of clients in the menu can be shorter. Agency users and TJDA administrators keep the same access.
• Such a user can also no longer accept the Data Processing Agreement for a client their account is not linked to: nothing is recorded, and the page says so.

What you get

• A client is only visible to the users linked to it, to the users of its own agency and to TJDA.

What is new

• On the Data Processing Agreement card in Settings, a user of an agency now sees only the date of acceptance, without the version or the email address of the person who accepted it. "Accepted by the client" is added only when Pulse recorded at the time of acceptance that it was made by a user linked to the client itself, not by a user of an agency; an acceptance from before Pulse kept that record shows only the date.
• TJDA administrators and users linked to the client itself see the card as before. Any other user sees only the date, with "Accepted by the client" under the same condition. Nothing changes in what is recorded when the agreement is accepted.

What you get

• Less personal data about the client's staff is shown to agency users.

What is new

• The Audit now explains one more notice that connector 1.4.0 can report about connector updates that were not installed (for connector 1.4.0, not yet released): an update that was stopped because Pulse no longer offered that release when the update started (it was withdrawn or replaced after the update was offered). Nothing is installed in that case.

What you get

• A withdrawn or replaced connector release is explained as such, instead of as an update started without a checked offer.

What is new

• The WordPress / WooCommerce section of the setup guide now says that a site on nginx with PHP-FPM needs fastcgi_buffer_size of at least 16k (and proxy_buffer_size when nginx forwards requests to another web server). The connector keeps its own cookies up to date in its responses, after a visitor gives consent and when consent is withdrawn (for connector 1.4.0, not yet released); those headers can be several kilobytes, and with a smaller buffer nginx answers that page with an error (502).

What you get

• A page error caused by a small server buffer is avoided before it happens.

What is new

• When the consent banner set in the connector (connector 1.4.0 or later) is your own consent cookie or Google Consent Mode, and the connector reports that banner as switched on but not active because the client's accepted Data Processing Agreement does not cover it yet (or the connector has not received whether it does), every visit at that site counts as no consent. When none of the last 30 leads and orders from such a site had marketing consent, Connector health now says this (for connector 1.4.0, not yet released) and points to the Data Processing Agreement line, instead of advising to check the banner setting (for your own consent cookie: the cookie name and the exact value).
• With any other banner, or when the connector reports the banner as active, the notice is unchanged.
• Nothing else changes: the same status, and nothing in what Pulse stores or forwards.

What you get

• The notice names the actual cause, so a correct banner setting is not changed for nothing.

What is new

• The Audit now explains a notice that connector 1.4.0 can report (for connector 1.4.0, not yet released): the connector sends its API key to Pulse without certificate verification, because another plugin or a setting on the site turns TLS verification off. The connector only reports this; it does not stop or change what it sends.

What you get

• A site that sends its key without certificate verification is visible, so the setting can be removed.

What is new

• When the connector reports that visitors carried a cookie from a different consent banner than the one set in the connector (for connector 1.4.0, not yet released), Connector health now says what to check: the setting “Consent banner on this site” in the connector, because consent is read only from the chosen banner. Cookies left from an earlier banner can also cause this notice. The status of the card does not change.

What you get

• A banner setting that does not match the banner on your site is easier to spot and fix.

What is new

• In New features per site, a feature that is switched on at a site is now shown as active only when the connector (1.4.0 or later) reports it as active there (for connector 1.4.0, not yet released). When it is switched on but the connector keeps it off for a reason other than the Data Processing Agreement (switched off by TJDA, no current Pulse configuration at the site yet, or, for the Click ID mirror, Landing capture is off at the site), the Audit says so instead.

What you get

• The Audit no longer reports a feature as active while the connector keeps it off.

What is new

• When a consent banner is set in the connector, Connector health now warns (for connector 1.4.0, not yet released) when none of the last 30 leads and orders that Pulse received from that site, from connector 1.4.0 or later and since the banner was set, had marketing consent (counted over at most 90 days). This replaces the count described in the entry “Audit: connector health, connector contact and the sites sending events”, which used the connector's own figures in the site's latest daily report. Leads and orders from older connectors, and from before the banner was set, do not count.
• If the connector does not report since when the banner is set, or a report carries no site name (including the shared entry for sites above the limit per key), the check says that it did not measure, instead of staying silent. If Pulse cannot read the figures, or received too many leads and orders in that period to check every site, the check says so. A site with a banner set but no leads or orders with its own address since then is reported as well.
• This check is informational: it does not change the Audit score, and it never changes what Pulse stores or forwards.

What you get

• A banner setting under which the connector never reads marketing consent is found from the last leads and orders that reached Pulse, not from one day of counts on the site.

What is new

• The Audit now explains the notices that connector 1.4.0 can report (for connector 1.4.0, not yet released) about the consent banner script, the Data Processing Agreement status, the remote configuration, the click mirror, withdrawn consent (including a cookie of the connector that was too large to move back to the session when consent was withdrawn), errors while the connector chooses which of its scripts to add to a page, an Elementor or WPForms form that was submitted before the connector could listen for its confirmation, and connector updates that were not installed (a missing or invalid signature, a download that does not match its signed checksum, an update signed for another Pulse address or with a key the connector does not trust, a site that cannot check signatures because neither the PHP sodium extension nor the sodium library that WordPress ships with is available, a failed download, an update started without a checked offer, or an error during the check), instead of only counting them.

What you get

• Every notice from the connector comes with a plain explanation.

What is new

• The Audit shows, per client, whether the accepted Data Processing Agreement covers the new features of connector 1.4.0 (click ID mirror, own consent cookie, Consent Mode as consent banner), and if not, why: not yet accepted by the client itself, accepted only by a user of your agency, a TJDA administrator or a user without a link to your organisation, or accepted before Pulse recorded who accepted. Per site it shows which of these features are switched on and whether the connector keeps them off (for connector 1.4.0, not yet released).

What you get

• You see why a new feature stays off, and what to do about it.

What is new

• When a user accepts the Data Processing Agreement, Pulse now also records that user's role, agency and link to your organisation at that moment, keeps the first acceptance unchanged and takes the IP address only from the connection itself. The privacy policy (version 2.2) lists these details, kept for the duration of the agreement plus 7 years. TJDA administrators cannot accept the agreement on your behalf, and a version that covers new connector features can only be accepted by a user of the client itself, not by a user of your agency.

What you get

• A fixed record of who accepted the agreement on behalf of your organisation.

What is new

• When part of the weekly report (mail and Slack) could not be loaded, the report now says so with a line such as "Section Campaigns unavailable this week (data error) — figures may be incomplete", and shows "—" instead of €0 or 0 for every figure from that part, including totals, week-over-week changes and action points.
• If Pulse truth could not be loaded, the report no longer says that server-side measurement is not live yet (webhook pending).
• If ad spend and clicks or the Pulse truth counts (purchases and leads) could not be loaded, no weekly report is sent that week, and TJDA is notified. A missing offline count or count of conversions without consent does not stop the report.

What you get

• A loading error can no longer look like a week with zero spend, zero conversions or no server-side measurement.

What is new

• The setup guide and the developer guide no longer say that Microsoft Ads and ChatGPT Ads count a browser conversion and a server conversion with the same event ID as one conversion. They now say what Pulse does: it forwards the event ID it receives unchanged and sends nothing to these platforms without one, so a browser tag set up as the guide describes carries the same event ID as the server conversion. How Microsoft and ChatGPT count such a pair has not been verified yet.
• The lead tip in the developer guide no longer says that a tag without the event ID always counts double; what each platform then counts has not been verified.
• Correction to the entries of 3 and 8 September 2026 (Microsoft Ads and ChatGPT Ads): the entries “New forwarding channels: Microsoft Ads and ChatGPT Ads” and “GTM container v2: Microsoft Ads and ChatGPT Ads browser tags” (3 September) said that browser and server deduplicate through the shared event ID; the entry “Client guide: Microsoft Ads and ChatGPT Ads sections, GA4 recipe and onboarding pre-flights” (8 September) said that one Microsoft goal receives browser and server through event-ID dedup; and the entry “Developer guide: dedup mapping, form fields and hard-won safety notes” (8 September) listed the Microsoft UET event_id as a deduplication handshake. For neither platform has this been verified. The entry “Events without an event ID: never sent with a made-up ID, and shown in the Audit” (17 September) said that a random ID could never deduplicate with your browser tags; that does not mean that a real event ID is deduplicated by Microsoft or ChatGPT: that has not been verified either.

What you get

• The guides promise only what Pulse does: it forwards your event ID unchanged. How Microsoft and ChatGPT count a browser and server pair is not promised until it has been verified.

What is new

• Pulse can now receive leads from the server function of a separate form app (for example a Bolt app on Supabase) with its own integration key, created by TJDA per app. Such a key only works for leads, only from a server (never from a browser), with an event ID from the app, and only with the agreed fields; contact details only as SHA-256 hashes. Pulse builds fbc from the click ID (fbclid) and the click time.
• Two new Audit checks: "Integration keys (form apps)" shows per key what arrived, what was left out and what was refused; "Integration key silence" warns when a key that sent leads before has sent nothing for a day.

What you get

• Leads from a form app on a subdomain can reach Pulse without putting a key in the browser, and you can see per key whether they arrive.

What is new

• A new Pulse remote settings page, linked from the Audit, lets you choose per client the country used to hash phone numbers that are entered without a country code (for example a Belgian number starting with 0). Pulse sends it to the WordPress connector with its signed remote configuration; connector 1.4.0 and newer use it (for connector 1.4.0, not yet released), older connectors ignore it.
• An order keeps using its billing country, and a number with + or 00 is always used as entered. Without a chosen country nothing changes: leads use the store country, otherwise the Netherlands, and orders without a billing country use the Netherlands.
• On the same page TJDA can switch off connector tracking for a client. Every change is logged, and a change of country is shown in the Audit for 30 days. As long as a country is chosen and a site of the client still runs a connector older than 1.4.0, the Audit says so, with the number of events.
• After a change the Audit may briefly report a different remote configuration version, until every site has fetched the new one (twice a day).

What you get

• Leads from sites outside the Netherlands, for example in Belgium, and orders without a billing country can match on phone number at the ad platforms.

What is new

• The setup guide now names the GTM variable that carries the Pulse event ID the way the Pulse container calls it: {{DLV - s2s_event_id}} (dataLayer name s2s_event_id), for the Transaction ID of the Google Ads lead tags and the eventID of the Meta tags. Before, the guide wrote {{s2s_event_id}}, a variable the Pulse container does not contain.
• Correction to the note of 17 September 2026 (Meta event ID): that note said tags send {{s2s_event_id}} and advised changing your own Meta tag to it. In the Pulse container the variable is called {{DLV - s2s_event_id}}.
• The optional view-through note for Microsoft and ChatGPT no longer says that their conversion tags deduplicate on the event ID; it says the tags and the event ID they send stay untouched.

What you get

• A tag set up word for word from the guide refers to a variable that exists in the Pulse container.

What is new

• For accounts that use their agency's Google Ads connection, Settings now says that the "Login Customer ID (MCC, optional)" field is not used: Pulse uses the agency's manager account.

What you get

• No doubt about which manager account Pulse uses for your Google Ads data.

What is new

• For visitors who gave consent: when an event from the WordPress connector or a Shopify order reaches Pulse within 71 hours (GA4 accepts up to 72), GA4 now records it at the time of the event instead of the time Pulse received it. For the WordPress connector that is the moment it built the event (for an order: when it became processing or completed, not when it was placed); for a Shopify order, the moment the order was created. Later events are still sent, and GA4 shows them on the day they arrived. Hits without consent never carry a time.
• A new Audit check, "GA4 event time", shows how many GA4 hits carried the event time and why the others did not.

What you get

• Consented orders and leads that reach Pulse late, for example after the connector retried, appear in GA4 on the day of the event rather than the day they arrived.

What is new

• When the WordPress connector reports a form or cache plugin that Pulse does not list yet (for connector 1.4.0, not yet released), the Connector health card now says how many sites did so (in the shared entry: how many reports), without the plugin name. Before, such a site could show as not having reported its plugins. Informational: it does not change the status.
• When a key has reached the limit of 10 sites per day, reports from further sites go into one shared entry. Pulse now adds up the notices of those reports instead of keeping only the latest one, and the card says how many reports the shared entry combines. The queue, consent and other figures in that entry still come from the latest report.

What you get

• Notices from sites above the limit, including conversions that were not delivered, are no longer overwritten; if a report cannot be combined, the card counts it as dropped. A plugin Pulse does not know yet is no longer silent.

What is new

• The Cookie extender card takes the last ad click of each conversion. If one of its clicks has no known time, the card no longer picks the click that does have a time: the conversion counts as “not in the buckets above”, because the unknown click may have been the later one. ChatGPT clicks are now included. This applies to every period you select.

What you get

• The click-age buckets only contain conversions whose last click is known.

What is new

• When the Google click validation or the forwarding pre-flight (Microsoft Advertising, ChatGPT Ads) fails, the Audit shows the HTTP status and, for Google, the error code, never the message text of the platform; TJDA can see the details. A product name, agency name or date with an ampersand or quotes is shown as written. An empty or unreadable answer from Google to the click validation is now shown as a failed check, instead of counting every click as confirmed.

What you get

• The Audit shows only what Pulse checked, not text from an ad platform that could contain account details.

What is new

• Where the dashboard cannot show your API key, it now says so: TJDA cannot read an existing key back, only create a new one. After that, your connector needs the new key.

What is new

• Some Audit checks (Reporting sync and a few checks for TJDA administrators) showed characters such as &, quotes and apostrophes as codes like & or '. They are now shown as normal text.

What you get

• Audit texts read as intended.

What is new

• A new Audit check Google Ads counting of conversion steps shows, for each active conversion step with a Google Ads action, whether the action counts as expected (One for leads, Every for purchases) and whether it counts the same as its browser action. Pulse only reads this setting once a day and never changes it.
• The check needs Pulse to read your Google Ads account in the daily sync. Where that is not yet the case, for example for accounts connected through an agency, the check shows "n/a" instead of a result.

What you get

• A lead counted more than once, or a step whose action and browser action count differently, is visible in the Audit.

What is new

• The public sign-up page no longer creates accounts, and the "Create one" link on the login page is gone. For a new account, contact TJDA.
• Self-service checkout is closed as well: an account or a new site cannot be created by paying online for now. Contact TJDA instead.

What is new

• For accounts where Pulse has prepared a key, a new Audit check Customer ID protection shows how the customer ID (external_id) is forwarded to the ad platforms that receive it. Pulse prepares a keyed hash (HMAC) with a key per account; until it is switched on, the check says that the customer ID is still forwarded as before (hashed with SHA-256).

What you get

• You can see whether the customer ID is forwarded as a keyed hash once that is switched on.

What is new

• A new Audit check Connector report retention (only for accounts whose connector sends daily reports) shows when Pulse last cleared the reports older than 90 days: the report and the site address are cleared; only the date and time of receipt, the source (event or configuration request), the connector version and the number of rejected reports stay. Before the first run it says that TJDA starts the cleanup.

What you get

• You can see that the technical reports of your connector are not kept longer than 90 days.

What is new

• The Connector health card now lists the form plugins and cache plugins that the WordPress connector (from 1.4.0) reports for the sites using your key (for connector 1.4.0, not yet released), as fixed names with the number of sites, and how many sites did not report their plugins. Informational: it does not change the status.

What you get

• You can see at a glance which form and cache plugins Pulse has to work with on your sites.

What is new

• A browser event ("source": "browser") sent with your API key without an event_id is no longer stored. Pulse answers 200 with {"status":"ignored","reason":"browser_without_event_id"}, so an existing tag keeps working. Without an event ID such an event could never be paired with the server event. Browser events with an event ID, and all server events, are handled as before.
• The Audit check "Browser events sent with the API key" counts these ignored requests.
• Channel performance: the fallback estimate of conversions missed for lack of consent (used when Pulse has no fuller count) now counts server events only, so a browser event is no longer counted on top of the server event it belongs to.

What you get

• Fewer meaningless rows, and a missed-consent count that no longer includes duplicates.

What is new

• A conversion without an email hash and without a LinkedIn click ID is no longer sent to LinkedIn, because LinkedIn cannot link it to anyone. The Audit shows it under Conversion delivery as skipped (no_identifier), as it already did for Microsoft Ads.

What you get

• No pointless uploads to LinkedIn, and the Audit shows how many conversions Pulse did not send to LinkedIn because they had no email hash or LinkedIn click ID.

What is new

• When an event arrives without marketing consent, Pulse now also empties the fields ip and user_agent on receipt, together with the click IDs, GA IDs and hashed fields it already emptied. The Audit check "Identifiers removed without consent" counts these too. With consent nothing changes. Events stored before this change are not changed.
• For new Shopify and Lightspeed orders without consent, the tracking data Pulse keeps per order no longer stores the GA4 client and session ID. IDs stored earlier with consent are kept.

What you get

• Less personal data stored for visitors who did not give consent.

What is new

• The Audit has a new line, Google Ads conversion time. For the last 7 days it counts which time each Google Ads upload used: the conversion time that was sent, the time the WordPress connector built the event, the Shopify order time, or the time Pulse received the event. It also counts how often the connector’s conversion time could not be used and Pulse fell back to the next time.
• Informational for now: it does not change the Audit score. Google Ads API uploads are not active yet, so the line shows nothing to count until they are.

What you get

• You can see how precise the conversion times sent to Google Ads are, and spot a shop clock that runs ahead.

What is new

• In Settings → GA4, the field for the web property is now labelled “Web Property ID (your browser GA4 property)”. The label was partly in Dutch and still referred to a comparison box that no longer exists.

What you get

• The field says what it is for.

What is new

• The Browser key card in Settings, the developer guide and the Audit no longer say that Pulse keeps a browser-twin count today. That count (the uplift figure) is not available yet; the texts now say so.

What you get

• No text suggests a figure that Pulse does not show.

What is new

• The setup guide no longer says that Pulse creates the Pulse click check conversion action itself. Your Pulse representative sets it up; what it does and why Google may show it as Misconfigured is unchanged.

What you get

• The guide describes how the click check action is set up today.

What is new

• Google Ads API uploads (offline conversions and the API fallback) are not active yet. Once they are, Pulse checks the conversion_time before anything is sent: a value that is unreadable, lies before the year 2000 or lies in the future is not sent. Previously an unreadable value would have been dated 1 January 1970.
• The Audit then shows such a conversion under Conversion delivery as skipped (invalid_conversion_time). One exception: if the value comes from the WordPress connector (for example because the shop's clock runs ahead), Pulse uses the next available time instead of skipping the conversion. From connector 1.4.0, the WordPress connector sends the checkout moment as conversion_time for orders from the classic checkout (for connector 1.4.0, not yet released). A conversion without a conversion_time gets the time the event was created: for the WordPress connector the moment it built the event (before any retry queue; for an order that is when the order reached processing or completed), for Shopify the moment the order was created. Events sent through the API or from Lightspeed without a conversion_time get the time Pulse received them, as does a connector or Shopify event whose own time is missing or unusable; if that is missing too, the conversion is skipped as no_receipt_time.

What you get

• Conversions keep their own date, also when the connector had to retry sending; a conversion Pulse cannot date is held back and shown, never sent with a made-up date.

What is new

• When an account is not active, the connector configuration endpoint now answers "Client account inactive", the same answer the event endpoint already gave. The site keeps the configuration it fetched last. Pulse records no contact or health report for such a site.
• For the configuration, a late payment does not change this: only whether the account is active counts.
• In the Audit, the "Connector contact" card of an inactive account now says the account is inactive, instead of asking you to check the plugin.

What you get

• An account that is switched off no longer receives configuration from Pulse, in the same way it can no longer send events.

What is new

• When the recipients of the weekly report include @users, the report now goes to the active users who are linked to that account in Pulse: the users created for it, and the users linked to it directly (for example a user who added a second site to their own login). Users of an agency who can see all of the agency's accounts are not added: they only receive the report of accounts they are linked to directly. A user who is no longer linked to the account no longer receives it.

What you get

• A user who manages more than one site with one login receives the weekly report of each of those sites.

What is new

• WordPress connectors up to 1.3.7 send the same placeholder as the customer ID for every guest order. Pulse now empties it on receipt, so Pulse no longer stores it or sends it to Meta, Microsoft Ads or ChatGPT Ads as if it were one customer. The event itself is stored and counted in Pulse as usual.
• Microsoft Ads needs at least one identifier, so Pulse no longer sends it a guest order without a Microsoft click ID (msclkid), email address or phone number. This shows under Conversion delivery.
• The Audit shows how often this happened in the last 7 days.

What you get

• Pulse no longer tells ad platforms that all your guest buyers are one and the same person.

What is new

• For accounts with a Pulse GA4 property, the Audit shows how many consented server purchases and leads of the last 7 full days and today carried no GA4 session ID, per connector version. Without a session ID, GA4 is expected not to link the event to the visitor's session or traffic source.
• It warns when connector 1.4.0 or later (for connector 1.4.0, not yet released) sent at least 5 such events and more than 20% of them had no session ID, per version or all such versions together.
• This check is informational for now: it does not change the Audit score.

What you get

• A drop in session IDs after a connector update becomes visible per version, instead of only a shift in GA4's source and campaign reports.

What is new

• For sites with the WordPress connector, the Audit shows two new checks. Connector health summarises the daily report that connector 1.4.0 and later send (for connector 1.4.0, not yet released): conversions that did not reach Pulse, notices, the local queue and consent per cookie banner, in fixed sentences with counts, plus how many leads from connector 1.4.0 or later carried an event ID made by the connector because the form did not pass a usable one, and how many server events still carried a different remote configuration version more than two days after a change. Connector contact shows when the connector was last in touch, marked as a warning after 48 hours and as failing after 7 days.
• For every account with server events, a third check, Sites sending events, counts the sites whose page addresses your server events carried in the last 7 days. It warns when that is more than one site, a site outside your domain, a test address or many different sites, which can point to a staging copy using your API key. A page address is a signal, not proof.
• Per API key, Pulse keeps the daily reports of at most 10 sites per day, and the contact of at most 10 sites, apart. When a key reaches that limit, Connector health and Connector contact say so, and what it means for sites above the limit.
• When a consent banner is set in the connector, Connector health names it, and warns when none of at least 30 leads and orders that the connector counted under that banner in a site's latest daily report had marketing consent (these are the connector's own counts, not the choices shown in the banner's dashboard). It also explains new notices: visitors carrying cookies from a different banner or from more than one banner, a lead or order with consent that arrived without the fields of the connector's scripts, and an invalid banner setting.
• These checks are informational for now: they do not change the Audit score.

What you get

• Problems on the site itself become visible in Pulse, instead of only a lower number without an explanation.

What is new

• The Microsoft Ads section of the setup guide now says that the UET lead tag in the GTM container sends the Pulse event ID ({{DLV - s2s_event_id}}) and exactly the same event name as the Pulse server conversion, and that TJDA checks this setup with a consented test conversion before Microsoft conversions go live.

What you get

• The browser tag and Pulse send Microsoft the same event ID and event name for a lead.

What is new

• The release notes listed connector 1.3.3 twice. That extra line also made the Audit check Connector up to date count one release too many for sites on a connector older than 1.3.3 (the status did not change, only the number of releases behind). The duplicate is gone, and the check now counts each connector version once.

What you get

• The Audit says exactly how many releases a site is behind.

What is new

• The setup guide now explains that the helper conversion action Pulse click check may show a warning status such as Misconfigured in Google Ads. Pulse only sends validate-only checks to it, so it never records a conversion.

What you get

• Less reason to worry about the status, and less risk of removing the action that powers the daily click validation.

What is new

• On a Google Ads card without an uplift section, Revenue difference (Pulse − Google Ads, same basis) now sits where Missed revenue was (that tile only showed a dash). Pulse revenue (measured) stays next to Claimed revenue. The info icon (ⓘ) says that the revenue difference is a difference between two totals (Pulse revenue minus what Google Ads reports for the mirror action of your purchase step, on the same value basis), not missed orders and not missed revenue: Google Ads does not report which orders it counted.
• Cards with an uplift section and cards of other platforms still show Missed revenue as before. Nothing else on the cards changes. This corrects the note “Google Ads card: Pulse revenue (measured) and the revenue difference with Google Ads” (2026-10-19), which said that Missed revenue stays a dash on a card without an uplift section: that tile is replaced by the revenue difference. The old note stays as it was published.
• On the Google uplift card, the percentage is now also shown when the comparison is only partly like for like, without a change of the conversion action set: a conversion action had no data for part of the baseline, and fewer than 4 baseline weeks remain after its last gap. Until now the card showed “Action set changed on … — not like for like” and no percentage. It now shows the percentage on both views, calculated on all baseline weeks. No correction is applied.
• Behind the info icon (ⓘ) next to the percentage: on Pre-delivery, the number of baseline weeks the shown percentage rests on (for a figure per euro: the baseline weeks with spend), that a conversion action had no data for part of the baseline, so the comparison is not fully like for like, and that the percentage is likely higher than a like-for-like comparison would show. On Last year, the note about the GA4 import when the synced Google Ads data shows that last year was measured with a GA4 import action and the current period with a web tag action, otherwise a general note; no note when the year-on-year actions are the same as the current ones. The card shows “Updated on 19-10-2026” on these views.
• When the volume is too low the card says “Insufficient data” and no percentage, where it showed “Action set changed on … — not like for like” until now. The other checks (4 full baseline weeks with spend for a figure per euro, incomplete spend, the minimum for the year-on-year comparison) do not change.

What you get

• A Google Ads card without an uplift section shows a revenue difference that is not mistaken for missed orders; the uplift card shows a percentage with a note instead of no percentage when the comparison is only partly like for like.

What is new

• Since 2026-10-06 the Google uplift card showed “Action set changed on … — not like for like” instead of a percentage, on both views (Last year and Pre-delivery), when a conversion action in the set got data only after the start of the baseline, or stopped. It now shows the percentage on both views again. Each view compares with the conversion actions that had data in its comparison period (for Last year: the actions set for the year-on-year comparison). No correction is applied.
• The note that the comparison is not like for like moves behind the info icon (ⓘ) next to the percentage. Only when the synced Google Ads data shows that the comparison period was measured with a GA4 import action and the current period with a web tag action, the note says that the GA4 import records fewer conversions than the web tag, so the percentage is higher than a like-for-like comparison would show. Otherwise it says that the comparison period was measured with a different conversion action. On Last year there is no note when the year-on-year actions are the same as the current ones.
• When fewer than 4 baseline weeks remain after an action’s data starts or resumes, or when the volume is too low, the card still shows no percentage, as before. The other checks (4 full baseline weeks with spend for a figure per euro, incomplete spend, the minimum for the year-on-year comparison) do not change. The card says from which date.

What you get

• The uplift card shows a percentage again after a change of conversion actions, with a note that says how the comparison differs.

What is new

• The Google Ads card now shows Pulse revenue (measured): the exact sum of the order values of the purchases with a Google Ads signal that Pulse measured in the range of the card (not before the Google Ads measurement start, if one is set), on the conversion value basis for Google Ads. It is not an estimate and not an average. Two lines under it split it into purchases with and without marketing consent.
• If one of those purchases has no usable value on that basis, if they are in more than one currency or have no recognisable currency, or if Pulse cannot read the purchases or the value basis, the card shows a dash instead of a partial sum, with the reason behind the info icon (ⓘ). If there are no such purchases, it says “0 purchases” and shows no amount. Amounts in another currency than the euro are shown with their currency code.
• Next to it, Revenue difference (Pulse − Google Ads, same basis): Pulse revenue minus the conversion value that Google Ads reports for the mirror action of your purchase step (the web action, by conversion time), in the same range. It can be negative. It is a difference between two totals, not missed revenue: Google Ads does not report which orders it counted. It is shown only when there is exactly one active purchase step with a mirror action and Google Ads data for that action in the range; otherwise the card shows a dash with the reason.
• Missed revenue stays a dash, and the other figures on the card (claimed conversions, claimed revenue, claimed ROAS, missed purchases and leads, total conversions) do not change. The explanations are behind the info icon next to each new figure, and the card says from which date.
• These two figures, and the note with the date, are shown only on a Google Ads card without an uplift section. They are not shown when the uplift section is there, also when it says “Insufficient data”, “building the trend” or shows a message. With an uplift section, the card shows the change in conversions before and since the start of Pulse, where it has enough data to calculate it, and not a comparison of Pulse revenue with what Google Ads reports.

What you get

• You see the revenue of orders with a Google Ads signal, exactly per order, next to what Google Ads reports, on Google Ads cards without the uplift section.

What is new

• Missed revenue, Total revenue, Real ROAS and the ROAS adjustment are no longer shown on the channel cards, and the Missed revenue column is removed from the table of missed conversions by campaign. They rested on an average order value, not on the exact value of each missed order. The cards and the table say from which date. In the campaign table, the caption “counted · no claim data” now reads “measured · no claim data”: “counted” is reserved for what the ad platform reports.
• On the Google uplift card, the line “Recovered by Pulse” (a number of conversions and an amount) is removed: both were estimates from a comparison with an earlier period, not counts. The percentage stays, titled “Change vs. the period before Pulse” (or “vs. the same weeks last year”): a comparison of periods does not prove the cause, so the explanation under it no longer says the change is “powered by the conversions Pulse delivers” but lists the possible causes. The caption under the percentage now reads “conversions per euro, compared with the earlier period”, and the error message “Uplift not calculated (data error)” (note of 2026-10-06) now reads “Change not calculated (data error)”.
• The numbers of missed purchases, missed leads and total conversions are unchanged, and so are the platform’s own figures (claimed conversions, claimed revenue, claimed ROAS). The amounts return when Pulse can calculate them exactly per order.
• Correction to the note “Channel cards: missed revenue only from missed purchases, and a value basis per ad platform” (2026-10-14). It described missed revenue as the missed purchases × the average Pulse order value and offered a value basis for it. That figure is an average, not the exact value of the orders the platform missed, so it is no longer shown, and the note on the cards that announced that calculation is replaced. The value basis setting stays, but it now only sets the basis of Pulse revenue on a card whose platform claims are still pending, and of its Audit check. The old note stays as it was published.
• Correction to the note “Claimed vs Real ROAS — and missed conversions on one time axis” (2026-08-29). That note called the missed conversions and revenue “a lower bound”, spoke of “your true return” and promised a framework “from cost to real return”. The number of missed conversions stays a lower bound. The missed revenue was an estimate, not a lower bound, and so were total revenue, Real ROAS and the ROAS adjustment, which included it; they are no longer shown. That note also advised using these figures for bidding (“so you can set bidding targets accordingly”, “directly usable for reporting and for setting platform ROAS targets”), and the card and the guide said to “set platform ROAS targets accordingly lower”. That advice rested on an estimate and is withdrawn. The old note stays as it was published.
• Correction to the note “Honest zeroes: channel cards show their working” (2026-09-10). It said the uplift hero shows “how many more conversions the platform measures since Pulse delivers”, as “part direct click recognition, part conversion modelling powered by our deliveries”, with “recovered conversions and revenue”, and that it reads conversions per euro, so “spend growth can never masquerade as Pulse effect”. That went too far. The hero compares weekly averages with an earlier period. It does not show how many conversions Pulse recovered, and it does not show the cause: the change can come from the conversions Pulse delivers, Google’s conversion modelling, seasonality or changes in the account. Per euro corrects for changes in spend only. The recovered conversions and revenue are no longer shown, and the explanation under the percentage now says this. A count of conversions recovered by Pulse is not available; whether and how Pulse can show one is still open. The old note stays as it was published.
• The setup guide says the same.

What you get

• The cards no longer show amounts that look exact but rest on an average.

What is new

• In the weekly report, the tile “Missed conversions” is now “No-consent conversions”, and the weekly mail and the Slack digest no longer call these conversions “missed”. They are conversions without marketing consent but with an ad-click signal. The wording “the ad platforms cannot see” was not correct (a platform can model some of these conversions itself), so it is gone.
• The count now follows the consent rule Pulse uses to decide what it sends to the ad platforms: at least one consent field, and an explicit yes in every one that is present; anything else counts as no consent. The previous count recognised fewer events as having no consent, so the count can be higher than before, also for earlier weeks. The order value next to it covers purchases only (a purchase without a value counts as 0), so it can be higher or lower than before. The weekly report says from which date.
• Under the current rule Pulse does not send these conversions to the ad platforms. Before 2026-09-16 a looser consent rule applied to sending (see the note “Consent: only an explicit yes counts”), so for weeks that begin before that date the report does not say they were not sent.
• If the count cannot be read, the weekly report, the weekly mail and the Slack digest now say “not available” instead of showing nothing or 0; the same goes for the Pulse truth figures (and the truth per funnel step) on the weekly page, in the mail and in the Slack digest, and the “Webhook integration pending” message no longer appears when only a query failed. The weekly mail always shows the line “No consent, ad-click signal” with the count (also when it is 0) next to “Pulse truth”.

What you get

• The weekly report says what the no-consent count is, and no longer suggests that the ad platforms cannot see these conversions.

What is new

• For accounts with a budget dashboard, a channel can now have a monthly budget from a given month. Its expected spend follows the months, spread evenly over the days of each month, instead of the yearly budget spread over 365 days. Totals, markets and campaign types that include that channel follow the same schedule, and so does Budget pacing in the Action list.
• Markets can be grouped: the group has its own row with its share of the budget, and its markets are listed underneath.
• A new part 6 shows separate campaigns: campaigns with their own budget and period outside the yearly plan, recognised by a word in the campaign name (LinkedIn Ads: also in the name of the campaign group). Their spend counts only there, with pacing spread evenly over the days of their period, and no longer in the channel rows, markets, campaign types, partner marketing, Not classified or Budget pacing in the Action list. Registrations and cost per registration are shown where they are known per campaign; for LinkedIn Ads, which reports registrations per account, they are shown as n/a. Part 6 lists the campaigns it recognised. Ad sets and ad groups are not split out yet.
• Under the total, a new row "Total incl. separate campaigns" adds the separate campaigns to the yearly plan.

What you get

• A campaign with its own budget no longer pushes a channel, market or campaign type over its yearly budget, and a channel that starts during the year is compared with the budget it has per month.

What is new

• Missed revenue on the channel cards and in the table of missed conversions by campaign now comes only from purchases the platform did not count: missed purchases × the average Pulse order value. A difference in value on a purchase the platform did count (for example because the platform receives values excl. VAT) is no longer counted as missed revenue. Total revenue, Real ROAS and the ROAS adjustment follow from that. The cards and the campaign table say from which date this calculation applies.
• Settings has a new Conversion value basis for Google Ads, Meta, Microsoft Advertising and LinkedIn: incl. VAT (the default, as before), excl. VAT, or excl. VAT and shipping. It sets which Pulse order value the card uses. Excl. VAT is calculated from the VAT amount your shop sends with each order, never with a fixed rate; purchases without a usable VAT amount are left out of the average (with incl. VAT, purchases without a usable value are now left out too), and the card says how many (with a basis other than incl. VAT, the Audit too). Excl. VAT and shipping only works for orders from the WooCommerce connector. What Pulse sends to the ad platforms does not change.
• Below 10 signals in the selected range, the card now also shows "insufficient data" for missed revenue, total conversions, total revenue and Real ROAS, and no ROAS adjustment or advice.
• Correction to the note "Honest zeroes: channel cards show their working" (2026-09-10). It said that conversions which carried a channel signal "could never be counted for lack of consent". That is not so for Google: Google may still include them as modelled (estimated) conversions if Consent Mode v2 is set up so the tag also fires without consent, the tag has an event to fire on, the container is not blocked, and there is enough volume to model. The Google Ads card now says so; the other cards say only that Pulse measured these conversions and did not send them. The same note said the card shows "insufficient data" below ten signals; until now that held only for missed purchases and missed leads.

What you get

• The ROAS adjustment no longer suggests lowering your ROAS targets because of VAT or other value differences on purchases the platform already counted.

What is new

• A closed or suspended account no longer appears in the client list of agency users and client users, and its pages can no longer be opened, also not through a saved link. TJDA admins still see every account.

What you get

• After an account is closed, its reports are no longer shown in the Pulse dashboard to the agency and client users who had access to it.

What is new

• When an account is closed, Pulse stops collecting data for it: the daily syncs with Google Ads, GA4, Search Console, Meta, Microsoft Advertising, LinkedIn and ChatGPT Ads skip it, the weekly e-mail and Slack reports are no longer sent, and orders from the Shopify app and Lightspeed are no longer processed for it, also after the Shopify app is installed again. The Audit shows Account not active instead of a stalled sync.

What you get

• After an account is closed, Pulse no longer fetches data for it from the connected ad and analytics accounts, and no reports go out.

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

• 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.