Hence I was wondering if there is a way to encode/obfuscate (even base64) this query data (similar to how its done when sending custom unstructured event data with the url redirect event (through the ue_px parameter). This would at least provide for a basic level of protection of data.
Unless you already have access to an encoded or obfuscated email address within the template I don’t think it will be possible to obfuscate as you won’t be able to execute Javascript within the email before the network request for the pixel is fired.
Yes - this is part of an email template. I can obfuscate the email once its substituted within the email campaign manager (Sailthru). But once I do that, the webhook will also capture the obfuscated email, which is not what I need…
The primary objective is to simply obfuscate the pixel url so its not readable by scanning the email source code easily but still allow the webhook to get fired and track the data.
You have a way set to do this with the uri_redirect event through the ue_px param but not sure if a similar approach is possible here.
As you can see, this url is fired as an image src for a pixel using the iglu webhook format.
If you mean that I cannot use an iglu webhook if I need to obfuscate the url, then how can I send additional data to the event (or even a custom unstructured event)? From the wiki page, I seem to have only a few params available eg.
UPDATE: I was able to send the data as an unstructured event to the pixel through the pixel tracker with ue_px base64-encoded event data, so thats a good step. However, it would have been useful to try to use base64 format with the webhook approach as well…
You’ll be able to pass ue_px for the Pixel tracker but not for the Iglu Webhook endpoint (as it only expects schema and data). If you absolutely need to use the Iglu webhook endpoint you may be able to send in the obfuscated email and then deobfuscate the email using a Javascript enrichment.
Thats what I suspected. Using the webhook format would make it easiler to implement and scale for the frontend developers in the team, but the pixel tracker does the job well enough along with protecting the data at a basic level!
One question re the pixel tracker: is there any way to suppress its firing when being previewed in the template? It wont make sense to track the impressions when the template with the pixel is loaded into the campaign manager and previewed by the editors…I doubt it but wondering about how such events are handled in general…
Does the preview pane have an email associated with it in the preview mode? If not you may be able to use some Zephyr logic to conditionally render the pixel if an email is not undefined.