Pixel and Redirect Tracking
Pixel Based Tracking
There are some scenarios where JavaScript or other non-executable systems are in play when using a tag or mobile app based solutions are not the best fit for data collection. A common scenario for pixel based tracking is tracking email opens, or for advertising impressions/pages where JavaScript requests are disallowed, but where you can embed an image or POST call.
The pixel endpoint decodes the included parameters and delivers them to the data collection pipeline, where it is mixed in with data from other sources like tagged websites or mobile apps. It returns a transparent 1x1 pixel as a result of the GET call.
Since Infinity uses a schema-less collection endpoint, you are free to add whatever key/value parameter pairs are relevant to your tracking needs. This is important for developers as it means that you can programmatically construct tracking events from within your own tools (or apps), and dynamically change what data is being sent depending on your needs.
At its simplest form, a call to track an e-mail open might look like this:
https://dc.oracleinfinity.io/v1/p?ora.inf.account=aaabbbcccddd&wt.mc_id=campaign1&wt.email_action=open
You may have noticed that pixel’s collection URL differs from other Infinity endpoints in that it does not contain an accountID as part of the endpoint URL. Instead, it is included as a query parameter. This is the only required parameter on pixel based tracking events.
While the payload on the above example is plaintext, it can also be sent as a base64 encoded block. Base64 encoding is currently the only option to obfuscate the presence of a tracking request. Some clients prefer a more obfuscated URL to mask the collected data (including the ability to mask the accountID), and this encoding capability provides that option.
This is an example of a Base64 encoded payload:
https://dc.oracleinfinity.io/v1/debug/p?b3JhLmluZi5hY2NvdW50PWFmbzBwbXQzNWYmZGNzc2lwPXd3dy5nb29nbGUuY29tJmRjc3VyaT0vJmRjc3JlZj1odHRwOi8vd3d3Lm9yYWNsZXBpa2UubmV0L29yaWdpbi9wbHVnaW5GaXh0dXJlcy8md3QubnY9dGVzdHMmd3QuZGw9MjQmd3QudGk9T2Zmc2l0ZSUyNTNBd3d3Lmdvb2dsZS5jb20lMjUyRiZkY3NkYXQ9MTU0NTE1NzI0MTQzNiZ3dC50ej0tNiZ3dC5iaD0xMiZ3dC51bD1lbi1VUyZ3dC5jZD0yNCZ3dC5zcj0xOTIweDEwODAmd3Quam89Tm8md3QuanM9WWVzJnd0LmJzPTE4NjR4OTAxJnd0LnNzbD0wJnd0LmVzPXd3dy5vcmFjbGVwaWtlLm5ldCUyNTJGb3JpZ2luJTI1MkZwbHVnaW5GaXh0dXJlcyUyNTJGZXZ0JTI1MkZ0ZXN0Lmh0bWwmd3QubGU9d2luZG93cy0xMjUyJnd0LnR2PTEuMC40Jnd0LmNlPTEmd3QudnRpZD0yZjE1YjE0NTc5Zjc3NDU4Y2E2MTU0NTE1MDAxNjY2NyZ3dC5jb19mPTJmMTViMTQ1NzlmNzc0NThjYTYxNTQ1MTUwMDE2NjY3Jm9yYS50YWdfaWQ9ZXZ0Jm9yYS50YWdfY29uZmlnPWV2dCZ3dC5kZWZlcnJlZHBheWxvYWQ9MSZ3dC5ldHM9MTU0NTE3ODg0MDQ2Ng==
The pixel endpoint also supports the debug option “/debug/”. This provides a success message, or an error message containing debugging data if the payload fails. When the debug flag is set, the endpoint returns the recorded data, with an 'ok' or 'error' as well as the payload (decoded if necessary).
It currently supports UTF-8 encoding as needed.
Here is an example of using the debug flag:
https://dc.infinitycloud.io/v1/debug/p?ora.inf.account=your_account_GUID&dcssip=www.google.com&dcsuri=/&dcsref=http://www.yourdomain.com/origin/pluginFixtures/&wt.nv=tests&wt.dl=24&wt.ti=Offsite%253Awww.google.com%252F&dcsdat=1545157241436&wt.tz=-6&wt.bh=12&wt.ul=en-US&wt.cd=24&wt.sr=1920x1080&wt.jo=No&wt.js=Yes&wt.bs=1864x901&wt.ssl=0&wt.es=www.yourdomain.com%252Forigin%252FpluginFixtures%252Fevt%252Ftest.html&wt.le=windows-1252&wt.tv=1.0.4&wt.ce=1&wt.vtid=2f15b14579f77458ca61545150016667&wt.co_f=2f15b14579f77458ca61545150016667&ora.tag_id=evt&ora.tag_config=evt&wt.deferredpayload=1&wt.ets=1545178840466
Redirect Tracking
Redirect tracking is supported on direct tracking events by appending a parameter (ORA.redir) with a URL encoded target address or as part of a base64 encoded payload. This cause Oracle Infinity to collect all include parameter data on the tracking event before re-directing a client browser to the redirect target. A successful redirect will return a “307 Internal Redirect” return code.
An example without Base64 encoding:
https://dc.oracleinfinity.io/v1/debug/p?ora.inf.account=[Account_GUID]&wt.co_f=[Client Identifier]&ORA.redir=http%3A%2F%2Fwww.google.com
The same example with base64 encoding:
https://dc.infinitycloud.io/v1/p? b3JhLmluZi5hY2NvdW50PVtBY2NvdW50X0dVSURdJnd0LmNvX2Y9W0NsaWVudF9JZGVudGlmaWVyXSZPUkEucmVkaXI9aHR0cCUzQSUyRiUyRnd3dy5nb29nbGUuY29t
Note: the ora.inf.account parameter is still required to identify the account to log this data even when using Base64 encoding. Likewise, you should still URL encode the target redirect address even though you’re also Base64 encoding it.
Troubleshooting
Much like other Infinity data collection methods, the best way to view data collected from tracking events is by using Infinity Streams. You can open a streams window and view pixel data post-collection to validate that it was received in the proper format.
If you’re having issues with data being received by the endpoint, you should start with the “/debug/” flag and test the tracking URL + payload in a browser window. This will allow you to confirm whether the format is correct, and allow you to easily intercept the feedback from the debug command.
Embedding into an e-mail
The most common use of pixel and redirect tracking in data collection is for collecting information about e-mail opens. The tracking code loads when the e-mail reader opens the e-mail and downloads images to display. It avoids being stripped out by security features that can interfere with embedded scripts as it is not technically a script itself, only a URL to an external site. Oracle staff will help you with the embedding this tracking code in Responsys and Eloqua, and most 3rd party providers will allow you to paste your customized URL’s in as well.
Note that some e-mail providers will block images or data from outside sites from loading by default, which can sometime interfere with logging data collection.
When setting up e-mail tracking, consider including some of the following parameters:
- WT.mc_id = [string] – this is a string value to identify the e-mail campaign. It can later be updated to a more meaningful yet readable value with a lookup table
IoT/DCAPI/SDK alternative
While the Oracle Infinity Data Collection API (DCAPI) is another way to construct ad hoc data collection for programmatic collection scenarios, it requires constructing and managing a JSON payload (for potentially nested events). This is a powerful tool, but is sometimes a bit too much for simple collection needs. This is where this pixel and redirect based tracking shines.
For embedded IoT applications in particular, it’s a quick, simple to use method to pass data back to Infinity over a web connection. In this format, it can serve as an alternative for very simple tracking needs where the full implementation cost and overhead of an SDK might be undesirable or too resource intensive.
Parameter Syntax - Syntax for parameter names and values.
Full Parameter Reference - Full reference of all available parameters.