Subscription to Weekly Report of People Who Visited Specific Web Pages

[Kathi_Gosche]

Has anyone been able to create a report that lists each person that visited a list of specific web pages and shows what those pages are? This is my dilemma: My sales manager wants a report sent weekly to each rep of all their leads that visited any of our recorded webinars in the last week. I have a solution if I can get around this one issue.

The plan:

1) Create a static list to record views for each rep with the column of Last Interesting Moment included (these page views would trigger an interesting moment)

2) Create a trigger campaign that adds those who visit the specific web pages to the appropriate static report

3) Subscribe user to list with a weekly delivery

4) Create a recurring campaign to remove all members of static list every seven days

The problem:

1) Lead views specified web page on Monday & the view is recorded in the Last Interesting Moment field

2) Trigger campaign adds the person to the list as desired

3) Lead visits some other page that creates an interesting moment, but not one of interest for this report, on Tuesday and overwrites the Last Interesting Moment

4) Report is pulled on Friday and lists the Last Interesting Moment from #3 instead of #1 and is of no meaning in the report. If they visit another webinar video, the new view would erase the info of the last video too.

How can I create a report that accurately records the web pages visited regardless of when the report is pulled? The sales manager does not want all interesting moments included in the report.

[Dan_Stevens_]

Kathi, please move this thread out of the "Marketing" section and into the "Products" section since it relates to the Marketo platform.

Out of the box, as you mentioned, Marketo only makes available the last interesting moment to you with the UI.  So what we did - to add more value in our MQL alerts to Marketing/Sales - is to create two history fields: one for Interesting Moments; and another to capture web pages visited.  By doing so, we can now include rich engagement insight in our alerts:

If this is something that you would address your problem, let me know and I'll provide more details.

[Kathi_Gosche]

Thanks Dan. That just might work, especially if I run another flow step to null the values in the fields every week after the report is sent.

[Dan_Stevens_]

So here's how you would go about doing this.  First thing you'll want to do - so that each web page is on it's own line (and not an endless concatenation of values) - is create a hidden line-break token (we created this at the top-most parent folder so that it would be available in any program) using Sanford Whiteman's approach documented here: http://blog.teknkl.com/dark-mkto-alleys-line-break-token/

Next, create your history field (type: text (not string)).  You'll then use this field in a "visits web page" trigger campaign (yours might be configured slightly different):

The full value of the concatenated value is:

{{system.dateTime}}: {{trigger.Web Page}}{{my.line-break}}{{lead.Avanade Web Page History}}

And finally, to display this properly in the alert, you'll want to create a velocity script token (within the program that will be sending out the alert) that will replace the hidden line-break with a </ br> tag:

and then insert this token in your alert:

[Kathi_Gosche]

Thanks Dan for the detailed explanation. I'll give it a try.

[Adele_Miller]

Hi Dan Stevens.

This is a fantastic idea!! Do you clear out the history after a while so the field doesn't get too weighty?

I worry for the most engaged people it might end up a little long, but maybe I am being optimistic

[SanfordWhiteman]

Trimming the history field is a good idea. But you definitely don't just want to empty it, you want to use some intelligent "windowing" so it always shows up to the last N events and/or events in a certain timeframe.

You can't do this with a Flow step alone. You need to pass the history field to a webhook that can munch the contents and give you back the trimmed results. And at the same time you need to be mindful of webhook overhead and not pass the history field to the 'hook unless you know/suspect it's too long. So maintain a separate score field as a counter, that'll tell you the number of history entries and when it goes over a certain number pass it to the hook for trimming.