Can Adobe Launch Encrypt or Obfuscate Values?

[eham06]

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

[jantzen_b]

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?

[eham06]

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

[dustins79436056]

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

Base64 encoding and decoding - Web APIs | MDN

[jantzen_b]

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.

[brandon_pack · Accepted solution]

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

[Alexis_Cazes_]

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

[chrisa38599900]

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.

[eham06]

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?

[brandon_pack]

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.

[Stewart_Schilling]

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).

[eham06]

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

[Stewart_Schilling]

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".

[eham06]

This worked! Thanks again...

[Stewart_Schilling]

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

-Stew