Just Because You Can, Doesn't Mean You Should: Solving Data Mapping Challenges

This post takes you through a common challenge in Tracardi automation workflows - extracting and mapping data - and how sometimes, stepping back and reassessing the approach saves time and effort.

The Challenge

How to get the contactid value from the URL?

The goal was clear - to extract the contactid value from a payload and map it to a profile trait. However, despite trying different variations of dot notation, regex matching, and so on and so forth things just weren't working as expected.

I'm not going to go into all the attempted configurations as there were many and more than a couple of hours spent exploring using a series somewhat complex automations.

The Fix

As always sleeping on it helped!

On reflection I realised that the solution could be resolved entirely by introducing a small JavaScript snippet for use with the Tracardi identification event. Instead of wrestling with automations, extracting and sending the value directly to Tracardi solved the problem cleanly:

<script>
  function getContactIdFromUrl() {
    var urlParams = new URLSearchParams(window.location.search);
    return urlParams.get('contactid');
  }
  function sendIdentificationEvent(contactId) {
    if (contactId && !isNaN(contactId)) {

      window.tracker.track('identification',{id: contactId},{"async": false});
    }
  }
  var contactId = getContactIdFromUrl();
  sendIdentificationEvent(contactId);
</script>

This simple script extracts the contactid directly from the URL's query parameters and sends it as an identification event. And best of all - no automation needed.

The takeaway - step away from the problem to find the solution.

Also, of interest is that whilst I wrote this post I continued to do a little bit of fact checking and this could have been a solution in an automation too.

Always learning 😉

Share a comment.

Have you faced a similar challenge?

Let's learn together!