I spent 20 minutes at 1:12 a.m. watching a Hotjar heatmap where 63% of taps hit the chat bubble because it overlapped the add to cart on mobile; nudged the CTA up 12px and conversion ticked up 18%, but the bot kept respawning on scroll like it was speedrunning my layout. Anyone else designing for humans and battling widgets with a death wish?
on scroll like it was speedrunning my layout. Anyone else designing for humans and battling widgets Same here — I used an IntersectionObserver to hide the chat when Add to Cart is 25%+ in view and only respawn after 3s idle, which stopped the ambush without tanking support; minor caveat: chat appears a touch later below the fold. You on Intercom or custom?
Short answer from my side: I’m seeing the same pattern — one concrete thing that helped was writing down the exact handoff and timebox it to 15–20 min. Does that match what you’re running into?
Had the same 1:12 a.m. Hotjar horror — fixed by delaying the chat until user idle + 8s or after first Add to Cart, then anchoring it 80px above the safe area on mobile. Building on @lclark900, a tiny MutationObserver snipes any respawn until the idle flag flips; much calmer heatmaps and no more “speedrunning my layout”.
I’d baby-gate the launcher with a dynamic bottom offset: use a ResizeObserver to read your sticky CTA/footer height, add env(safe-area-inset-bottom), then pipe that into the widget’s “vertical padding” so it can’t drift over the CTA. If the vendor won’t expose an offset, mount the launcher inside a fixed container you control; quick ref for env(): env() - CSS | MDN. Which tool is it — Intercom, Crisp, Drift?
I tamed mine with a MutationObserver that catches the widget when it re-injects, moves it into my own container, and toggles pointer-events: none whenever it overlaps the buy button so taps pass through. Felt like whack-a-mole at 1 a.m., but MutationObserver - Web APIs | MDN made it reliable, and if your vendor exposes a hide/show API that’s cleaner.