Tracking clicks on any element

Hey, I’m a frontend dev trying to get to grips with Snowplow. I’ve got a basic setup working and I see things like events on links are easy enough to track. However, say I wanted to do something like track a click on a button that was outside a form or on an element like a div or image…it seems like I would need to create a custom event?

What would be the best approach to tracking events like clicks on different elements?

If I follow these docs am I on the right path or am I overcomplicating this? Designing tracking - Snowplow Docs

Yep - generally a custom (self describing) event is the way to go here. Although you can also use structured events I’d be tempted to go for custom events as they give much more flexibility. How you implement this tends to be based on your application e.g., a single generic event, click_element vs specific to an application product_image_click.

What would be the best approach to tracking events like clicks on different elements?

There are a couple of different ways to do this - tag managers (like Google Tag Manager) are common as they contain generic ‘gtm.click’ events as well as decorating certain elements with data attributes to either track or not track.

1 Like

Thank you @mike
I was just reading the docs on self-describing events and one thing I can’t work out is what snowplow_name_here is referencing — is that the App peram?
So where says appId: 'sp-static', // you can specify your own app name here or is that name something else?

Oh or actually now I look again would it be the tracker name so in this instance try?

The docs I’m referencing are: Out-of-the-box vs custom events - Snowplow Docs

I still don’t fully understand even after reading the docs how I would define and fire a custom event. What would an example be for something simple, like you want to pass some info about a button a user clicked on?

Do I need to define a custom context first, how does that actually look in a practical example?

Seems like the examples/tutorials that put it all together haven’t ever been finished Tutorial: define, track and query your own custom event - Snowplow Docs

Hi @squaredindex,

Unfortunately, the tutorials are a section of the documentation that hasn’t been kept up to date or finished. We’re sorry for that and have plans to improve them.

The main documentation for the trackers is a better place to get help with instrumenting tracking. For example, here you can read about custom self-describing events and here is more information about tracking custom context entities with the events in the JS tracker.

To answer your question, the snowplow_name_here is in most cases just snowplow. So you would call window.snowplow(...) to interact with the tracker. It’s very unusual to change it to something else, the tutorial was being perhaps too careful.

How the events that you track would look like really depends on what you want to capture with the button presses. Custom context entities are not mandatory but help you reuse the same entities across different events. For example you can track a user entity with your events.

Please do ask specific questions that you need help with. One more resource for you to review is a tutorial for tracking self-describing events here on Discourse.

1 Like

Thank you @matus.

Personally, I still get lost on 3. Define a JSON schema for each of the events/context types.
So once you’ve defined your schema in JSON, where do you host that? Can you host it locally to test? It doesn’t seem to specify.

With Iglu, the description of what it is doesn’t mean anything. " Iglu is built on a set of technical design decisions. It is this set of design decisions that allow Iglu clients and registries to interoperate."…ok cool, that tells me nothing, that’s like me saying “hey I’ve invented this thing” and you ask “what does it do?”, I respond “well it was made using technical design decisions”.

I’ve read the docs and still feel I’m missing the key info. I’m not from a data background, but I’m a front-end dev, but it feels completely inaccessible.

Hey @squaredindex

For Iglu schemas, you need an Iglu Server, or a static Iglu repository (basically a folder, hosted somewhere, which you can generate with igluctl) to store and host your Schemas.

You can test them locally with Snowplow Micro. This allows you to place your custom schemas in a local folder to Snowplow Micro, and it will validate them. This requires Docker to use. You could also host a Snowplow Mini on AWS or GCP which would offer a better UI (Elasticsearch) for inspecting the events.

I do think so reading around Events and Entities as well as tracking design with Snowplow would be beneficial.

I’d suggest starting here:

And then work down the naivgation on the left hand side.

Upon posting this, I now realise this is in the Try Snowplow category!

One of the limitations of Try Snowplow is that you can’t build custom events and entities. This is because those trial pipelines don’t have their own Iglu repositories! So we’d advise as part of the trial to simply use the built in recipes and examples to try out Snowplow.

If you want to go deeper with Snowplow, then you could try the Open Source Quick Start (which does have Iglu Repos) or jump straight to Snowplow BDP and let Snowplow do the heavy lifting + training on lots of these concepts.

2 Likes