Upgrading our digital surveys:
a plain-English guide
What we have, what we're building, why it matters commercially, and what to ask the product team. Written to be read in ten minutes.
1. The one-paragraph summary
Our pop-up surveys work and sit on a genuinely strong backend, but every capability beyond "show a big survey when the page loads" requires the customer's web developers to write code — and that is exactly the market gap Hotjar exploits. We have prototyped, working end to end, the upgraded system: a small non-blocking survey widget that marketers configure entirely from CustomerGauge — where it appears, who sees it, when it triggers, and what customer data rides along with each response, captured automatically from data the customer's website already exposes. Install once, then never touch the website again.
2. What we have today — honest strengths and limitations
Looking at our own Survey Builder and Distribution screens:
- The survey builder is mature. Fifteen question types including NPS, NPS Drivers, CES, CSAT, matrix groups, ratings and reviews; multi-page surveys; a branding library with logos, fonts and button styles; full multi-language support.
- Frequency control exists. The Distribution tab has "Frequency (days)" and "Pop-up delay (seconds)" — so we can already cap how often a visitor sees the survey on repeated page hits.
- The backend is our moat. Responses land in real time in reporting, trigger close-the-loop workflows and alerts, and sync to CRM. Hotjar has none of this — they collect feedback and stop.
- Gaige AI Interviews is already appearing in this surface — the upgraded widget gives it far more places to run.
- One format: a large modal (up to 768px) that takes over the page. No small corner popover, which is the format visitors tolerate and Hotjar leads with.
- Two behaviour settings. Frequency and delay are the entire configuration surface. No "show at 50% scroll", no "show on exit", no "only on checkout pages", no "only for enterprise accounts", no sampling — all of that is JavaScript the customer must write.
- Getting customer data in is clunky. The "Add Parameter" flow generates an embed code with empty placeholders —
"segment_l": "","segment_v": ""— and a developer must write code to fill every one, on every page, and keep it working forever. This is the single biggest friction point, and it is why survey deployments stall in customers' web-development queues. - Any change re-enters the dev queue. Want the survey on a different page, or a new data field? That's a website change, not a CustomerGauge change.
- Data hygiene: every display creates a non-response record (skewing response rates and consuming contact quota), and pop-ups bypass the duplication rules.
See it yourself: the baseline demo simulates exactly this behaviour on a fake shop — big modal, and watch the log count a non-response record on every appearance.
3. Where we're going: the Hotjar model
Hotjar's advantage is not better surveys — ours are stronger, and everything after the response is no contest. Their advantage is time-to-value: a marketer installs one script via Google Tag Manager in ten minutes, and every survey after that — creating, targeting, triggering, stopping — happens in their dashboard with zero developer involvement. The website is touched once, ever.
The upgrade gives us that model:
- Small popover widget — a ~360px card in the corner that never blocks the page, minimizes to a tab instead of closing, with the existing modal still available. (Extended demo — scroll halfway.)
- Triggers configured centrally — on load, after delay, at scroll depth, on exit intent, on a button click, or on an event the site fires ("order placed"). Changed in CustomerGauge, live in minutes, no code deploy.
- Audience targeting — URL rules, device type, percentage sampling, and attribute conditions like plan = enterprise. (B2B portal demo.)
- Automatic data capture — the answer to "hard to get all the fields in", below.
4. The data breakthrough: fields without developers
Most customer websites already announce rich data on every page, because Google Analytics requires it. Any GTM-instrumented shop pushes the GA4 ecommerce schema — order ID, order value, currency, products — into a standard structure called the dataLayer. Product pages carry schema.org data; campaign links carry UTM tags.
Our prototype's field discovery scans a page and lists everything it exposes, with live values. A marketer ticks the fields they want, and every survey response arrives with that data attached — no parameters wired by hand, no developer. The scanner also recognizes the standards: it labels ecommerce.value as order_value, flags emails as PII, and suggests canonical names so every customer's data lands in CustomerGauge under the same vocabulary. That consistency is what makes cross-customer benchmarking possible later — and it is why GA4 support is essential rather than nice-to-have: it is the one schema most of our customers' websites already speak.
Try it: the discovery bookmarklet works on any website — including a prospect's, live, during a sales call.
For fields beyond the standards, responses carry a flexible attributes object stored in a queryable JSON column with a registry and a one-click "promote to segment" path — so customers never wait for us to add a field. (Engineering detail is in the spec; the principle for this audience: structured where we know, flexible where we don't, promoted when proven.)
5. How the prototype illustrates the journey
Everything below is live at cg-survey-widget.pages.dev and is working code — the widget is 21 KB with automated tests, not a design mockup.
| Demo | What it represents |
|---|---|
| Baseline storefront | Today. The current pop-up's behaviour and its costs, made visible — including the non-response counter. |
| Extended storefront | The consumer journey. Scroll-triggered NPS popover; exit-intent "sorry to see you leave" survey; GA4 dataLayer fields attached to every response automatically. |
| B2B portal | Our core market. Logged-in account context (plan, account manager, renewal) attached via one line of code; relationship NPS after login; order-effort survey fired by an "order placed" event. |
| Survey Builder prototype | The future Distribution tab. Where "Frequency + Delay + Add Parameter" is today, this adds triggers, audiences, page fields and live preview — the config it produces is exactly what the widget consumes. |
| Discovery bookmarklet | The sales weapon. Show any prospect their own data, mappable into CustomerGauge, during the first call. |
6. Roadmap — what we need to develop, and why
| Phase | What | Why / who |
|---|---|---|
| Done | Widget, trigger engine, discovery, builder — as prototype | Proves UX and de-risks the design. No platform changes were needed to get here. |
| Phase 1 | Config endpoint (serves builder settings to the widget) and response ingestion contract | Platform team — the critical path, now unblocked. Both key questions are answered yes: records can be created on arrival (the anonymous-survey mechanism), and a config endpoint can be built. The API specification is ready for estimation. |
| Phase 2 | Builder UI into the real product (Distribution tab evolution); GA4 field dictionary ships with discovery | Product + platform. GA4 is essential: it's the data most customer sites already expose, so surveys carry order context with zero customer dev work. |
| Phase 3 | Record semantics: impression-based counting, server-side frequency, JSON attributes column + registry + promotion | Platform. Fixes response-rate accuracy, contact-quota leakage, and makes "any field, later" a standing capability. |
| Phase 4 | GTM Community Gallery template, docs, pilot customer | Marketing + CS. "Live in 10 minutes from Tag Manager" becomes a sales line we can prove on a call. |
7. What to ask the product team
- Answered yes: responses can be created on arrival via the anonymous-survey mechanism (sent date = completed date = now()) — no pre-created non-response record needed.
- Answered yes: a new config endpoint can be designed and built. The full API specification — config, responses, events — is ready for the platform team to estimate.
- Can responses carry a queryable JSON attributes column with a registry, with promotion to segments? (Phase 3; a memo-field shim is acceptable as a bridge.)
- Confirm the two-tier privacy stance: PII allowlist per account for auto-captured fields.