Expand my Community achievements bar.

SOLVED

Can Adobe Launch Encrypt or Obfuscate Values?

Avatar

Level 4

Can Adobe Launch take a value from the query string, encrypt or obfuscate that value and push the encrypted/obfuscated value to Adobe Analytics?

If so, how?

How would be decrypt/un-obfuscate those values stored in Adobe Analytics?

Thanks

1 Accepted Solution

Avatar

Correct answer by
Employee

I'd also recommend you take a look at the SDI Toolkit Extension from Search Discovery.  They added functionality that might be of interest to you.  It is a one-way hash but will hash to consistent values.

Here is their description:

One Way Hash

Converts a data element to a consistent obfuscated string.

One way hashing is commonly used to obfuscate sensitive information for analytics purposes. Hashing an email address or a customer id will return the same obfuscated value every time for tracking purposes.

user@example.com => 4da3a5736c67e46036f26146662a6e9491176a63de36b49b7ed2c5b47b37e96e

View solution in original post

14 Replies

Avatar

Level 10

I'm not aware of any feature to encrypt/decrypt values between Launch and Adobe Analytics. Can you tell me more about your use case?

Avatar

Level 4

We have customer user IDs.  These customer user IDs are exposed as plain text in the URL string. It's our company policy not to store plain text customer user IDs in 3rd party tools such as Adobe Analytics.  We are allowed to store these customer user IDs as obfuscated/encrypted values.  I am looking for a way to use Adobe Launch to obfuscate or encrypt these values and push to Adobe Analytics.

Thanks

Avatar

Level 4

You can base64 encode using the JS methods btoa() (encode) and atob() (decode).

Base64 encoding and decoding - Web APIs | MDN

Avatar

Level 10

I'm sure there are plenty of way to obfuscate the userID with custom JavaScript within Launch. However, I'm not aware of a way to de-obfuscate these values once they reach Analytics.

Avatar

Correct answer by
Employee

I'd also recommend you take a look at the SDI Toolkit Extension from Search Discovery.  They added functionality that might be of interest to you.  It is a one-way hash but will hash to consistent values.

Here is their description:

One Way Hash

Converts a data element to a consistent obfuscated string.

One way hashing is commonly used to obfuscate sensitive information for analytics purposes. Hashing an email address or a customer id will return the same obfuscated value every time for tracking purposes.

user@example.com => 4da3a5736c67e46036f26146662a6e9491176a63de36b49b7ed2c5b47b37e96e

Avatar

Community Advisor
I would not use SDI Toolkit One Way hash as it uses eval function which poses security and performance risk

Avatar

Level 2

I think the main problem is that you have the value in the querystring. Even if you obfuscate the values sent in the analytics payload, the plaintext version will still be sent in the referrer. We had a similar issue with email addresses in plaintext in URLs. The only surefire solution is to stop putting PII in URLs.

Avatar

Level 4

Brandon... Thank you... I think this is the solution that we need! :-)

One quick question.  Is there a way for me to run this One Way Hash locally on my system on all of my IDs?

Avatar

Employee

Not sure exactly of the specifics that you mean by running it locally, but according to their documentation it is using a 64 character SHA-265 hash (https://www.searchdiscovery.com/blog/sdi-toolkit-extension-for-launch-by-adobe/ ) which can be implemented in almost any language of your preference and even some in Excel VB Script if search for it.   Haven't tried any of these but there are a number of free ones out there (ex: GitHub - Caligatio/jsSHA: A JavaScript implementation of the complete Secure Hash Standard family (S...  Some perform better than others:  test ) or some lanaguage have them built in like PHP: hash - Manual.  The algorythm is the same so as long as it's implmented correctly, white space is trimmed, etc. the IDs should hash to the same value as the one you implment through the Launch extension.

Avatar

Community Advisor

Yes, The same hashing function (SHA256) can be used on the keys within your CRM so that you can make the connection between the hashed values in your analytics data and your customers in your CRM.

Here's how I would do it in R. Take note that I'm applying the same data normalization (force to lowercase & trim whitespace) as I do within the SDI Toolkit's one-way-hash.

#####THIS IS AN R Script

library("digest")

setwd("/Users/stewartschilling/R_Scripts/inputs")

sampleCRMdata<-read.csv(file="sampleData_custID.csv", header=TRUE)

sampleCRMdata$custIDHashed <- sapply( tolower( trimws( sampleCRMdata$custID ) ), digest, algo="sha256", serialize=FALSE)

#####HERE ENDS THE R SCRIPT

My advice to you would be to run a small sample of your CRM custId's and make sure that you get the same hashed output from both ends (Launch client-side and CRM server-side) before you go great guns with data collection (or in using the hash as an integration key in ECID service or AAM).

Avatar

Level 4

I had not thought about using R.  Thanks for the tip...

I have the following set up...

   custID.csv contains 1 column, 2 rows, 1 ID in each row.

   read.csv is a blank file.

  When I run your code, I get the following.  Error message in bold.

> library("digest")

>

> setwd("/Users/Eric/Documents/R-Data-Files")

>

> sampleCRMdata<-read.csv(file="custID.csv", header=TRUE)

>

> sampleCRMdata$custIDHashed <- sapply( tolower( trimws( sampleCRMdata$custID ) ), digest, algo="sha256", serialize=FALSE)

Error in `$<-.data.frame`(`*tmp*`, custIDHashed, value = list()) :

  replacement has 0 rows, data has 1

Do you have any recommendations?

Thanks

Avatar

Community Advisor

read.csv is actually an R function. It pulls in the file, /Users/Eric/Documents/R-Data-Files/custID.csv and puts it into a new data frame by the name, sampleCRMdata.

The file, custID.csv, can have as many columns as you want as long as it has one column with a header of "custID".

Avatar

Community Advisor

Glad to hear it!  Thanks for the follow-up.

-Stew