I am a Journey Builder newbie and I have noticed that the Test module of the tool is not completely reliable. Moreover, the History tab of the journey does not give a coherent view of the journey. Even when I filter it down to a specific contact I notice that the activities are not shown in chronological order.

So I have been adviced to use an extra Data Extension to log the activities within the journey. A log with one row per entry to the journey with columns for the activities I would like to keep track of.

Knowing there will be new rows (entries) to the main Entry Point Data Extension every time the automation runs, what is the best practice to keep this second DE consistent with the Main Entry Point DE? Should a new row be added to this one, too or is there a better way of handling that.

Also, note that the new version of a journey might have new activities or activities removed or replaced. In such cases how should this second DE stay in the loop without a lot of effort?

UPDATE: In other words, I would like to know what exactly is and has happened to a contact who has entered the journey using only one row with their unique Contact Key.

  • 1
    I've had a similar usecase. I used an ampscript that I injected in every sendable activity in the Journey. It's a basic ampscript with Contactkey and other info like the name of the email/sms, senddate, .. Every time an activity is sent, the ampscript would log the info un a DE. This way, you don't have to worry about the entry source.. Oct 11, 2019 at 12:54
  • @RachidMamai Could you elaborate a bit on the injection part? Also, my most crucial activities are Decision Splits where I'd like to monitor which path are my entries taking. Oct 11, 2019 at 13:14

1 Answer 1


You can use the Update Contact Activity in order to update a data extension based on a customer's pathway through your journey. You could use this method, for example, to identify exactly who is in a journey, where they are at and what date/time they entered/exited, etc...

If you wanted more granular data around whether they have been sent/opened/clicked an email or SMS, then you could add in an accompanying automation to update data inside of your data extension. The advantage of pairing these two approaches is that you can write more efficient queries since you'd know enter/exit dates, current path, whether they are in they journey or not, or any other metric you are capturing with Update Contact.


If you are going to use your journey entry DE as the source for your update contact activity, and you are worried about keeping track of a user's history in the journey through each version, then it's probably a good idea to keep the fields you are updating generic so that they will extend across any anticipated versions without needing to be constantly reconfigured.

I'd also recommend including a few fields to populate inside of this DE in order to make things a little easier to manage.

In_Journey (set to true as first activity and false at any step that would remove the person from the journey)

Entry_Date (set to current date/time as first activity in journey)

Journey_Version (set to current version as first activity in journey)

Exit_Date (set to current date/time at any step that remove someone from the journey).

There will surely be other pieces of data you could use that fit your specific use-case, but that should be a good start.

  • Yes, it would eventually be an Update Contact activity. But should I create a separate DE per journey with ContactKey as the primary key? If that is the case, what is the best practice for the fields within the journey? How would this new DE be aware of the new entries to the journey? Should the Automation that is running the entry point also update this second DE? Oct 15, 2019 at 7:55
  • 1
    Unless you are adding a ton of additional data for each user in the journey, I would just add additional fields to your journey DE and then use the update contact activity for that. Oct 15, 2019 at 15:25
  • This sounds reasonable and simpler than other suggestions I have found elsewhere. One drawback is that if the journey gets a new version with a different structure, this should also be applied to the Entry Point DE. It gets a bit difficult to keep track of what happened during the previous versions. Am I right? Have you thought this also through? I would be grateful if you could update your answer with your solution so that I can accept it as answer. Thank you in advance! Oct 16, 2019 at 11:42
  • 1
    I've updated my answer. Oct 16, 2019 at 14:30
  • Fantastic, could you also briefly explain what you mean by "keep the fields you are updating generic"? Oct 16, 2019 at 14:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .