0

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

1 Answer 1

4

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.

5
  • 1
    Very good explanation. I would not be too concerned about the mapping of email to email in contact builder. This assumes one would use the default data extensions directly in Journey Builder. I really can't think of a single use case where this is feasible. Instead, processing (utilising Query Activity in Automation Studio) the IGO data model into a single denormalized DE; mapped with 1:1 cardinality on Contact Key in data designer, is indeed a better way to go. Jun 4, 2021 at 7:16
  • Yes. I agree. Use cases are sparse for using raw PI/IGO DEs. Your way's the way to go for Contact Builder, @LukasLunow
    – Macca
    Jun 4, 2021 at 15:07
  • Thanks all for your relevant help! Jun 9, 2021 at 9:01
  • Sorry I got one more question. Do you know how long Einstein stores the data? I've heard, that it only stores data for 90 days? Jun 11, 2021 at 9:33
  • @Anna_orellfuessli I'm not aware of any particular data retention in place for profiles held by Einstein. There might be, but not 9 months. Anecdotally, I just took a look at one of my clients' account that's had recs set up for a little while and I can see purchases going back to 2018 that are there and still associated with contacts. The IGO/PI data extensions don't have any data retention policy set up, either. Email recommendations are cached for 72 hours.
    – Macca
    Jun 11, 2021 at 22:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.