INTEGRATIONS · EXPERTINI ATS

Google Analytics 4

Paste your GA4 measurement ID and your public job pages start reporting traffic to your own Analytics property.

2 min read · Updated July 2026 · Expertini Editorial

You cannot improve what you cannot measure, and for hiring the first measurement is simple: who is looking at your jobs? The Google Analytics 4 app connects your public job pages and careers site to your own GA4 property with a single setting — paste your measurement ID, save, and traffic starts flowing into the same Analytics account your marketing team already uses.

The gap this closes is the black box between publishing a job and receiving applications. Without page analytics, a role that attracts no applicants is a mystery: is nobody seeing it, or is everybody bouncing? With GA4 on your job pages you can see traffic sources, geography, devices, and behaviour — and combine that with the pipeline data inside the ATS to diagnose exactly where candidates drop off. The integration is honest about ownership: it is your GA4 property, your data, under your account and Google's standard free tier. Expertini charges nothing for the connection, and setup takes less time than reading this page. If diagnosis shows the listing itself is the problem, the job posting best practices guide is the next stop.

▶ Watch the 30-second overview — no sign-up needed

01Setup is one field

Create or reuse a GA4 property in your Google Analytics account, copy its measurement ID, and paste it into your ATS settings. From that point your public job pages and careers site load your GA4 tag and report page views, sessions, and sources like any other site you track — including a custom-domain careers site, which reports under your own domain.

02Your property, your data

The ATS never proxies or stores your analytics — traffic reports directly to the Google property you own. That means your existing dashboards, audiences, and team access in Analytics apply immediately, your data outlives any tooling change, and your measurement ID is the only thing the ATS holds.

03From traffic to hires

GA4 tells you which sources send visitors; the ATS tells you which sources send hires. Read together, they answer the questions that actually allocate budget: which channel fills this kind of role, which jobs get traffic but no applications, and where the application flow loses people. That closes the loop from first page view to signed offer inside one pipeline view.

Engineering notes

Platform architecture & operations

A1Connection architecture

This app is configuration-based: what you save is acted on directly by the platform — no third-party account link is involved. Settings are validated on save, stored per organisation, and take effect on the next request.

Changes are immediate and reversible; removing the configuration stops the behaviour visibly. As with every connector, secrets (where any exist) are stored encrypted and shown only as presence flags.

A2Write semantics and data flow

Every data movement is an explicit action with a logged result. Writes happen on your click — or automatically only where you enabled a rule (auto-push on hire is off by default, per-provider). Reads — imports of people, accounts, or files — run when you press Import, deduplicate against what you already have (clients by name, people by email), skip rather than overwrite, and report created-versus-skipped honestly, which is why re-running any import is safe by design.

Each action writes a row to the app-activity journal (ats_app_activity): what ran, when, for which record, and the outcome — including the vendor's own error text verbatim when something fails. Usage reporting inside the ATS aggregates that same journal, so integration reporting and integration reality cannot diverge.

Anything that leaves the request path — notification fan-out, webhook delivery, activity journalling, mail — runs in fire-and-forget background threads. A slow external endpoint can never make the interface hang, and a failed side effect is logged rather than silently retried into inconsistency.

A3Operational considerations

Connections are organisation-level and gated to owner and admin roles; recruiters use the features a connection powers but cannot connect, disconnect, or reconfigure. Disconnecting removes stored credentials immediately and stops the dependent features visibly, not silently. Data already imported stays yours and editable.

Imported people arrive marked as imported with conservative privacy defaults — no consent is assumed for anyone who never filled in your application form, and retention defaults apply. Everything written is yours to take: CSV exports and the Data Export app cover the same stores the product itself reads. The exit is as open as the entrance — by design, not concession.

A4Placement in the integration topology

This integration is live in the registry today. One connection per provider unlocks every feature it powers, and the topology grid below shows the neighbouring connectors in the same capability area — statuses come from the same registry that drives the in-app hub, so this page can never claim more than the product does. For anything the catalogue does not cover, Webhooks and Zapier are the generic, documented escape hatch.

Dependency map

Connection typeconfiguration-based (no third-party account)

Secrets at restencrypted; UI shows presence flags, never values

Action journalats_app_activity — one row per action, vendor errors verbatim

Auto-push rulesoff by default, per-provider, every run logged

Registry statuslive

Interface blueprint

Structural schematic of the surface — panels, hierarchy, and interaction affordances. A contract, not a screenshot.

Connection card

● connected — presence flag

scopes: minimum required disconnect

Actions

push — explicit clickimport — deduplicated

Activity journal

Fig. 1 — Google Analytics 4: structural interface schematic. Panels and states are the contract; data shown is placeholder.

Interaction flow — states, validations, feedback

Every state below is enforced server-side; the interface reports it, it doesn't decide it.

Open app pageowner/admin only for changes

Save settingsvalidated on save (format, live checks where possible)

In effectnext request uses the new configuration

Journalactions logged to app activity

Invalid value → named validation error; nothing partial is savedRemoved configuration → behaviour stops visiblySecrets → presence flags only, never re-displayed

Fig. 2 — interaction flow: navy = states, gold = server-enforced gates, green = confirmed outcomes; tags list the edge cases and their feedback.

Frequently asked questions

What do I need to set this up?⌄

A Google Analytics account with a GA4 property — free from Google — and its measurement ID. Paste the ID into your ATS settings and tracking begins on your public job pages.

Does Expertini see or store my analytics data?⌄

No. Traffic reports directly from candidates' browsers to your own GA4 property. The ATS stores only the measurement ID needed to load your tag.

Does this cost anything?⌄

The connection is included in your Expertini subscription, and Google Analytics 4's standard tier is free from Google. There is no analytics add-on fee on either side.

Which pages are tracked?⌄

Your public-facing pages — job listings and the careers site — including when they are served from your own custom domain. The authenticated ATS workspace is not part of your public tracking.

At a glance

One-field setup with your GA4 measurement ID
Traffic reports straight to your own property
Works with custom-domain careers sites
See sources, geography, and behaviour per job
Combine with pipeline data to find drop-offs
No analytics add-on fees on either side

See google analytics 4 on your own hiring.

Bring a real job description to a 30-minute demo — free trial included.

Book a demo