Einstein Email Recommendation Set User Info

Question

I'm trying to figure out how to implement Einstein Email Recommendation - especially how to implement the codes and I'm still confused with the SetUserInfo Code:

<script type="text/javascript">
_etmc.push(["setOrgId", "MID"]);
_etmc.push(["setUserInfo", {"email": "INSERT_EMAIL_OR_UNIQUE_ID"}]);
_etmc.push(["trackPageView"]);
</script>

If I would use the email adress would it say {"email": "email=?"}]); and same with the SubscriberKey {"subscriberkey": "subsriberkey=?"}]);

Moreover in some conversations I found out that Einstein Email Recommendation is not properly working when using the subscriber key as identifier. Is that still true?

How are your experiences with Einstein Email Recommendation?

thanks for your help.

Anna

Answer 1

There's no perfect answer to this one, but a little of the history may help to explain.

Back at its inception many years ago, IgoDigital (now Einstein Email & Web Recs) made an assumption that the best way to uniquely identify site visitors was by using their email address. Questionable, but somewhat understandable. They were naive times back then. The point is, the use of the name "email" for the unique identifier was established and its legacy still carries over to this day.

Over time, users came to the view that embedding the visitor's email address in the clear in URLs/query strings was probably not a great idea due to fairly obvious privacy concerns and increasingly when implementing Igo/PI/Einstein we looked for other, less sensitive identifiers to use in the place of the actual email address. Whatever value you chose, the collect call would look like this:

<script type="text/javascript" src="https://123456.collect.igodigital.com/collect.js"></script>
<script type="text/javascript">
    _etmc.push(["setOrgId", "123456"]);
    _etmc.push(["setUserInfo",{"email" : "myuniqueid123"}]);
    _etmc.push(["trackPageView"];
</script>

After the purchase of Igo by ExactTarget and the efforts to integrate the two products started, the developers continued with the assumption that we'd be using email addresses to uniquely identify visitors. The IGO data extensions were added to the Email product allowing you to do segmentation based on your Collect data and it was decided to hard-code the relationship between these tables and the Contact Model in Contact Builder based on email addresses (Contact.EmailAddress = Igo.Email). The devs then moved on to create the Email Recommendations block for Content Builder. Again, the assumption was carried forward and again they hard-coded that assumption into the design of the Email Recommendations Block. Development of Marketing Cloud products is campaign based, the devs moved on to the next big thing and the assumption was never revisited.

So, it's a bad idea to use the actual email address of the visitor for the "email" but not using email address and using some other value breaks the Contact Model and the stock Email Recommendations block. What to do?

The best way to think of the Einstein Email Recommendations Block or Behavioural Trigger Block is as template generators. They generate the code for you to copy and paste into the actual HTML/Free Form block you'll actually use in your email. Once you've configured your recommendations block, flip to the HTML view of the block and you'll see something like this:

<table>
  <tr>
    <td>
      <a href="https://123456.recs.igodigital.com/rr/v2/123456123456123456a123ab/l/1/%%emailaddr%%">
        <img src="https://123456.recs.igodigital.com/rr/v2/123456123456123456a123ab/i/1/%%emailaddr%%">
      </a>
    </td>
    <td>
      <a href="https://123456.recs.igodigital.com/rr/v2/123456123456123456a123ab/l/2/%%emailaddr%%">
        <img src="https://123456.recs.igodigital.com/rr/v2/123456123456123456a123ab/i/2/%%emailaddr%%">
      </a>
    </td>
  </tr>
</table>

The code's not very good as it doesn't work very well on mobile devices, so you'd probably want to edit it, anyway. But, notice the "emailaddr" personalization string appended to the end of the URL for the image and link. Replace this with whatever value you have in the Email Application that corresponds to the value being used for the "email" in your Collect. For example, if that's the SubscriberKey used in the email app, your amended block might look like this:

<table>
  <tr>
    <td>
      <a href="https://123456.recs.igodigital.com/rr/v2/123456123456123456a123ab/l/1/%%_SubscriberKey%%">
        <img src="https://123456.recs.igodigital.com/rr/v2/123456123456123456a123ab/i/1/%%_SubscriberKey%%">
      </a>
    </td>
    <td>
      <a href="https://123456.recs.igodigital.com/rr/v2/123456123456123456a123ab/l/2/%%_SubscriberKey%%">
        <img src="https://123456.recs.igodigital.com/rr/v2/123456123456123456a123ab/i/2/%%_SubscriberKey%%">
      </a>
    </td>
  </tr>
</table>

Note: You should consider the sensitivity of the data you're using for the "email". If you're considering using the SubscriberKey, spare a thought for whether the SubscriberKey is, itself, sensitive and if it's knowable. SubscriberKeys are frequently sensitive and/or consist of an incremental value, like a number. Beyond the scope of this response, but you'll frequently see hashes of an identifier that the data layer of your tag manager and the Email Application both know being used. The SQL Server HASHBYTES() function that you can use in Automation Studio gives you an easy way of hashing the email addresses or SubscriberKeys of your subscribers. If you don't need a strong hashing algorithm, you can also use AMPScript's MD5() function at time of send to populate your "email" value in your URLs. The main thing is the value you use in your URL and the one in Collect must match and not leave vectors of attack for the nefarious to exploit.