Questions fréquentes

Create the site in your account, then copy the two tags shown in the settings. They are pasted into the header of every page you want to measure, before the closing head tag. The first one declares your site identifier, the second loads the script asynchronously. No other change is required.

The first measured page load comes through immediately. The online visitor counter works on a five-minute window: if nobody has been through since, it shows zero even when the installation is correct. The indicators for the day fill up as visits come in.

In this order: the code really is in the page header and the page has been republished; the site identifier you pasted does match this site; your own IP address is not in the exclusion lists of the account or of the site; your browser is not running a blocker that cuts off the measurement request. The Test the installation button, in the site settings, tells you whether data is actually coming in.

Yes. One caveat though: most tag managers re-inject the external script without copying its attributes. That is why the first tag declares the site identifier and the collection address in a global variable. So keep both tags exactly as they are provided to you, including inside a tag manager.

Yes. The script watches browsing history changes and records a new page view on every route change. Scroll depth tracking is reset when the new view is displayed. You have nothing to trigger by hand.

No. The same snippet is added once, in the shared template of your site. The page path is read automatically on every load.

The file is around 12 kB, so under 5 kB actually downloaded once compressed by the server. It is loaded asynchronously and therefore never enters the critical rendering path. Measurements are sent through the browser beacon mechanism, designed not to delay navigation.

Technically the script would work, but the result would be unreadable: only the page path is recorded, not the domain name. The home pages of two domains would therefore appear as a single row. Create one site per domain, each with its own identifier. Subdomains follow the same rule if you want to be able to tell them apart.

The site settings offer a Test the installation button. It queries the collection server and tells you whether data has arrived, showing either a visitor active right now or the number of hits received since the beginning of the month. Publish the page, visit your site, then run the test again.

There are two IP address exclusion lists: one for the whole account, in your profile, and one per site, in its settings. You can enter a single address or a whole range in CIDR format, in IPv4 as well as IPv6. The exclusion also covers heatmaps. It only applies going forward: visits already recorded stay in the statistics.

For audience measurement, the question only arises if Pulsar Analytics is your only tracker. The script writes nothing on the visitor's device, so there is nothing for them to accept. An embedded video, a map, a chat or an advertising tag, on the other hand, still require consent, and the banner remains necessary for those. The decision to remove the banner is yours, after reviewing everything your site loads.

The conditions are cumulative: the measurement must serve the statistical purpose of the site alone, the data must be neither matched with other processing nor passed on to third parties, there must be no tracking of browsing from one site to another, and the resulting data must remain strictly limited to anonymous statistics. The Pulsar pixel is designed to meet these conditions. It is up to the site publisher, as controller, to check that their actual use meets them as well.

No, and nobody should tell you otherwise. A tool does not make a site compliant: it makes a compliant configuration possible. You remain the controller for the measurement of your own sites, and therefore for informing your visitors, for your record of processing activities, for your other trackers and for your other processing. Pulsar Analytics covers the audience measurement part and provides you with the documents that support it.

Yes. The information obligation of Articles 13 and 14 of the GDPR does not depend on consent. Mention audience measurement in your privacy policy: statistical purpose, absence of cookies, retention periods, identity of the processor and hosting location. Our public privacy policy gives you the exact wording.

For the audience data measured on your sites, you are the controller and Pulsar acts as processor within the meaning of Article 28 of the GDPR. For your account and billing data, the publisher is the controller. This distinction is set out in our privacy policy, which covers the two sides separately.

The data processing agreement is published online and binding, with no prior request. It covers the points required by Article 28(3): documented instructions, confidentiality, security measures, rules for sub-processors, assistance with rights requests or data breaches, deletion or return of the data at the end of the service, and provision of the information needed for an audit. A signed copy can be requested in writing.

Audience data is hosted and processed in Switzerland, which benefits from an adequacy decision of the European Commission. Billing data is processed in the European Union, in Ireland, by the payment provider. No audience data is transferred outside this perimeter.

Raw measurement data is kept for 25 months at most, with an automatic daily purge. The aggregated heatmap data, which is nothing more than counters per cell and per page, is kept for 12 months at most. These periods are enforced by a scheduled task, not by a promise.

They can always make the request, to you, as controller of the site concerned. In practice, the absence of any persistent identifier and of any directly identifying data means that no row can be linked to a specific person, the situation covered by Article 11 of the GDPR. We assist you in handling the request and in wording your answer.

It is a self-assessment document generated from your account. It reflects your actual configuration: measured sites, absence of cookies, IP address truncation, rotating daily identifier, no sharing with third parties, retention periods, hosting locations. It is neither a label, nor a certification, nor a decision by an authority: it is a document to present, alongside the privacy policy and the data processing agreement.

No. Since 2026, the CNIL no longer publishes a list of pre-approved audience measurement tools. The process has become a documented self-assessment by each site publisher. Be wary of a tool that claims to be certified by an authority: authorities do not certify tools.

They remain cookieless and store nothing on the device. Clicks and a sample of movements are counted per cell and per page, without any identifier: an individual's journey cannot be reconstructed, unlike session recording, which Pulsar does not perform. Form fields and blocks marked as masked are excluded from the capture. It is still up to you to assess this feature in your own analysis, since you are the one who turns it on.

A hit is a page view or a recorded event. So page views, outbound clicks, downloads, clicks on an email address or a phone number, scroll milestones and your custom events all count. The time-on-page measurement, sent once at the end of the visit, is not counted. Heatmap points are not counted either: they are stored separately, as counters.

The server computes a fingerprint from the current day, the site identifier, the truncated IP address and the declared browser, all with a secret salt. This fingerprint changes every day and is not stored on the visitor's side. An accepted consequence: two people on the same network, with the same browser, count as a single visitor; one person moving from desktop to mobile counts as two. The figure is a reliable order of magnitude, not a headcount.

A session, or visit, groups the events of a single visitor for as long as they are not inactive for more than thirty minutes. New activity after that gap opens a new session. Since the visitor fingerprint is daily, a visit that spans midnight in universal time is counted as two sessions.

It is the share of sessions that viewed only one page. This definition is the classic one and is easy to read, but it differs from that of Google Analytics 4, which works on engaged sessions and takes time on page and events into account. So do not compare the two rates with each other: compare each one with itself over time.

The script only accumulates the time during which the page is actually visible, and sends that total once, when the visitor leaves. A background tab is therefore not counted. If the browser is closed abruptly, the send may not happen: read the average duration as a floor, never as an exhaustive measurement.

Clicks to an external domain, downloads of common file types, clicks on an email or phone link, and scroll milestones at 25, 50, 75 and 100 per cent. Measuring the time actually active is automatic too. Each of these events uses a hit, except the time measurement.

A call such as pulsar('signup') is enough, with a second argument holding your properties if needed, for example pulsar('signup', { plan: 'pro' }). Calls made before the script has finished loading are queued and sent afterwards. Twenty properties at most are kept per event, each truncated to 255 characters.

They send an event when an element of the page becomes visible, once per element, with no code for you to add. You designate the element with a selector, class, identifier or attribute, from the site settings. A second mode fires the event as soon as an element matches the selector, which makes it possible to count a form switched to its sent state, for example. It takes a few minutes for a change to apply on your site, the time for the configuration to refresh.

A goal targets either a specific page path or an event name. The dashboard shows the number of conversions and the number of visitors concerned over the period, along with a curve. There is no step-by-step funnel: Pulsar counts conversions, it does not reconstruct a journey in several steps.

The pixel only determines the country, derived on the server before the IP address is truncated, and never the city. Cities only appear if you have imported a Google Analytics history, which does contain that dimension. This is a deliberate limit: the city brings audience data much closer to data that singles out an individual.

The page path is recorded without the query string and without the anchor. This is a minimisation measure: URL parameters often carry identifiers, tokens or search terms. Campaign parameters, on the other hand, are read and stored in their own columns, which leaves you campaign tracking without keeping the rest.

Only the referrer domain is kept, never the full URL of the originating page. So you know that a visit comes from a site, not from which specific article. Here again, the point is not to store more than a statistic requires.

The rule is simple and readable: a paid campaign medium classifies the visit as Ads, an email medium as Email; failing that, a referrer recognised as a social network gives Social, a search engine gives Organic, the absence of a referrer gives Direct, and everything else gives Referral. Since ad networks do not add campaign parameters, the script infers the paid origin from the presence of a click identifier in the URL, without ever keeping that identifier, which would be unique per click.

No, and a gap is normal. The definitions differ, starting with the session and the bounce. Above all, on many sites Google Analytics only loads once the banner has been accepted, whereas Pulsar measures from the very first page. Depending on the case, Pulsar shows more visitors than Google Analytics, or fewer if a blocker intercepts one more than the other. Compare trends, not absolute values.

Two things. The daily totals of the property, namely page views, users and sessions, which extend your curves into the past. And the monthly breakdowns by dimension: channels, sources, pages, entry pages, campaigns, devices, browsers, operating systems, countries, cities and hourly distribution.

It brings over neither your custom dimensions or metrics, nor your events, nor your e-commerce data, nor the detail of individual visits, nor scroll depth, which Google Analytics does not measure in the same way. Imported data consists of aggregates, not event rows: it therefore cannot be cross-referenced.

The site settings give you an address to add as a Viewer on your Google Analytics 4 property, in access management. You then run a scan of the properties visible to that address, choose the one that matches your domain, and start the import. No write access is requested, and you can withdraw the access from your side whenever you want.

Because it is stored by isolated dimension, month by month, and not row by row. Crossing a source with a country, for example, would require data that the import does not contain. As soon as a filter is active, only the data measured by the pixel is displayed, and the dashboard tells you so rather than making up a figure.

Yes, nothing prevents it technically. Bear in mind that keeping Google Analytics keeps the need for a consent banner, which cancels part of the point of the exercise. An overlap period of a few weeks is useful to understand the differences before deciding.

The imported data is deleted and your curves only go back as far as the installation of the pixel. You can start the import again later if the read access is still in place on your side. Remember to export beforehand, if that history matters to you.

Advertising audiences and remarketing, multi-channel attribution, step-by-step funnels, session recording, export to a data warehouse and native integrations with advertising tools. These are not development delays: the cross-matching that those features require is precisely what would forfeit the benefit of the consent exemption. If your business depends on it, keep an advertising tool and its banner.

One site and 2,000 hits per month, with the full dashboard and real time. It has no end date and asks for no credit card. It is an offer, not a trial period in disguise.

A fourteen-day trial gives you access to the dashboard as soon as the account is created. At the end of it, you choose a paid plan or move to the Discovery plan. Without a choice on your part, access to the dashboard is paused, but nothing is deleted in the meantime.

Measurement is not cut off overnight. We tell you so that the tier or the plan can be adjusted, and you make the change yourself. An occasional overshoot caused by a news spike is not a problem.

From the Subscription page of your account. Each plan sets the number of sites, from one to forty, and a dropdown chooses the monthly hit volume. The change takes effect immediately and the proration is computed by the payment provider.

Yearly billing amounts to ten monthly payments: two months are not billed. The contents of the plan are identical either way. You can switch from one to the other from the Subscription page.

Enter your company details in your account, including your intra-EU VAT number. The number is checked against the European validation service: if it is recognised and outside Luxembourg, the reverse charge applies and VAT is not invoiced. Your invoices can be downloaded at any time from the Subscription page.

You can cancel at any time, with no notice period and no justification. Deleting a site or an account is confirmed through a link sent by email, valid for sixty minutes: it is deliberately a two-step action, because it cannot be undone. Export whatever you want to keep before confirming.

Yes, as with any measurement tool, including Google Analytics. The script is not an advertising tracker and calls no advertising domain, which limits blocking, but some filter lists target measurement domains in general. No honest vendor can promise you a hundred per cent of visitors. We do not try to work around these blocks: a visitor who refuses measurement should not be measured against their will.

From our own infrastructure, in Switzerland, with no third-party delivery network. The file and the collection endpoint are therefore our responsibility end to end, which avoids adding an intermediary to your chain of processors.

Two things: the domain that serves the script as a script source, and the collection domain as a connection destination. Both addresses appear as they are in the code snippet provided in the site settings. The script calls no other origin.

Nothing visible to your visitors. Sends do not wait for a response and errors are caught: a page does not break and shows no error if collection fails. In exchange, the events from that period are lost and will not be caught up.

No. Measurement relies entirely on a script executed in the browser. There is no image fallback and no server log analysis. This is a limitation shared by almost every audience measurement tool.

The API is read only and returns the same figures as your dashboard, computed the same way. It exposes the list of your sites, real time, the totals for a period, a time series and the breakdowns by dimension. The key is passed in a header, the rate is limited per key and per minute, and a lost key is revoked then replaced. No writing is possible, by choice.

No. You have CSV, Excel and PDF exports from the dashboard, and the read API to feed a third-party tool. There is no real-time event stream and no export to a data warehouse.

Each site can publish a viewing link, with no account to create and no editing rights, real time included. The link is revoked in one click from the site settings, which makes it immediately useless. Anyone holding the link can view the dashboard: treat it as a moderate secret.

Encryption in transit and at rest, data partitioned per site, rate limiting on the collection endpoint, filtering of bots and unwanted referrers before recording. Backups are automated and their freshness is monitored: a backup that is too old raises an alert on our side.