Event Tester
Test your destinations by sending custom events to them through Freshpaint
Last updated
Test your destinations by sending custom events to them through Freshpaint
Last updated
For destinations with a server-side connection, Freshpaint provides a way to send test events so that you can experiment. This method of testing is useful for a few reasons:
You can see that your destination is working as soon as you have set it up
You can test changes to properties in precision track events before you deploy them in your code
You can debug your destination's configuration (for example, how you organize events there)
To use the event tester, locate a destination that supports server-side connection mode and click the configure button. You'll see a button for the event tester on the screen that follows:
Once you click the test event button, you'll see the tester interface, which looks like the following:
When you send test events, you begin by selecting the kind of event you want to send to your destination. You can choose any of the event definitions available in your project; these will be sent as track events. You can also choose to send a page or identify event - more on that in a second.
The event properties contains a JSON object which represents the event payload. Here's what they mean:
The distinct_id is the user_id of the user performing the event.
token is your Freshpaint environment identifier. This is what you would use to install Freshpaint's autotrack snippet on your website, and it isn't a sensitive piece of information.
time is time that the event will appear to be from when your event is sent to the destination. It's given as a Unix timestamp - the number of seconds elapsed since January 1, 1970.
You can have any number of custom properties - one is shown here as an example (named test-property).
When you're ready to send your event, click the Test Event button. You'll see something like the following as a result:
Shoot! It looks like our event didn't go through. Let's dig deeper into what we see here.
When you use the event tester, we show you a version of the request we made to the destination, in the form of a Unix curl command. This is so that you understand how we're communicating to the destination, and it also allows you to send the request from your computer if you wish, simply by executing the curl command yourself.
You'll notice that there's a header in the request, Api_key: REDACTED. The Iterable API Key is a sensitive password that allows access to your Iterable account. While our request to the destination included the real API key, we don't want to show it in the results to people testing a destination, so we redact that and any other sensitive information that we find.
The response shows what the destination sent back. Looking at it, we see that they say No user exists with userId test-user-id. Iterable requires that users have a known distinct id, so if we want to send a test event there, we need to give it something it will recognize.
This time, I put in an email address I knew Iterable would recognize - et voilà, it worked!
In addition to track events, you can send pageview events to destinations.
In the Event Library, you can create Pageview events which will trigger the "Track" action in the destination. The Freshpaint System Page event is fired the same way, when a user loads a new page, but it will instead trigger automatic pageview actions (supported by certain destinations).
You can send identify events to your destinations, in addition to track events. When you try that, you'll see that the event structure looks a little bit different:
You'll see some of the same fields used in the example above, and some other ones. Let's look at what's new:
$device_id is the session identifier. Everyone user that can be tracked by Freshpaint has a device id that indicates their session. We send this identifier to the destination so that they can attribute anonymous track events to the person being identified with distinct_id.
$user_props is a collection of related properties which will also be attributed to the user. In this case, we're sending firstname and lastname, although you can send any named property that you wish, with any data that you want.
Testing identify events otherwise works just like testing track events.
You will be sending real events to your destinations with the event tester, so if you prefer to not to retain test data there, you'll need to delete those test events from your destination later.
Some destinations charge by the number of events you send them, so you may be incurring some real costs for the test events you send them!
