Testing Segment’s Visual Tagger

We recently put Segment’s Visual Tagger to the test. Our goal? To identify best practices for implementation and ongoing usage for our clients. After applying Visual Tagger across all pages of MammothGrowth.com – including forms, CTAs and internal & external links, we’ve discovered several best practices that will make your Visual Tagger experience more successful.

Quick Conclusion: Visual Tagger will help increase time-to-value for new Segment clients immensely.

Key Benefit: Visual Tagger is a great solution for collecting basic data for early analysis.  And it provides the proof-of-concept necessary for obtaining buy-in for tagging additional custom events. Getting early data is a huge win while waiting for custom events to be implemented.

For simple sites or landing pages, Visual Tagger offers immediate value by providing most, if not all, required data without any additional custom events. For larger or more complex sites, additional features and flexibility in the tagger would help drive value with our clients.

Pros: Cons:
EXTREMELY easy setup and installation – Zero dev work needed for basic tagging of events specific to your site (not just generic submission/click/view events). Since tagger is not retroactive – you don’t get a count/preview of events as you build – so you’ll still need to wait to collect data for analysis after required events are identified.
Great for individual events – eg. when it appears only once on a page and/or once on the site Not convenient for building events like ‘click ANY CTA’ or differentiating between CTA clicks by path. Default properties and enhanced rule options would help this. Eg. You can create ‘Click Any Product’ on a product page with multiple options, however with current functionality could not create a property to differentiate which product was clicked, so would need one event per click for any product-specific questions – ending up with a lot of events rather than properties to differentiate. **Workaround by creating multiple events with the same name**
Manual properties allow for immediate customization – which is great.  (However, beware of the need for standardization; avoid awkward naming conventions inconsistency.) No event for form field changes – basic conversion questions on the type of sites where this tool has tons of standalone use would benefit from field change events.
UX for testing is very clear and intuitive – green light means go! The testing step and warnings will likely result in cleaner events.
Really fast load time of the tagger versus other similar tools
Overall UX for creating/editing is very intuitive – multi-select for editing and same UI for editing as for creating is great.


Feature Notes:

When testing, here’s an easier way to refresh/reset on the testing page to check multiple actions against the defined event: test if it IS firing where needed and NOT firing where you don’t want it to.

The UX for the property option to ‘select from page property’ (which can capture button text or input field value) is not intuitive – look closely for this.

The UX of adding properties is awkward (eg. click ‘select from page’ and you can’t go back and instead have to delete the property. You also have to un-click the pointer icon to add the next property).

Events from the Tagger show up in Segment’s debugger – but do not appear in destinations.

When publishing, open a new browser or refresh before checking in the debugger.

Cannot duplicate events easily from inside the tagger.

The “form submit” event capture of input values suggests all radio options as properties.  It does not ignore radio/select boxes or allow for ‘active’ only.

Wildcards for selector and rules not currently allowed.