Expand my Community achievements bar.

SOLVED

Page/URL Impact to Conversion and CR Metrics

Avatar

Level 4

Hello Everyone, 

 

Something that has been a visualization challenge for me is trying to determine what impact a page or URL has to our conversion metrics

 

Form Submits - a metric based off a segment for visitors that reach a URL that contains "thank"

CR to Submits - [Form Submits] / Visits

 

When I attempt to look at a list of URL's I only see URL's that are the actual thank you pages: 

 

Damonwhall_0-1666889217722.png

When i filter out than you pages, no other page gets attribution to these metrics because they are hit based.  

 

I can only see impact to these metrics by creating page "groups" and making them visit based:

 

Damonwhall_1-1666889355467.png

 

The issue with this, is that if I ever wanted to see a list if individual URL impact to Form Submits and CR, I will have to make a "visit" based segment manually for each one.  

 

Is there a more efficient way of doing this?  

 

We are looking to see this in a simple table and not a flow display or a fallout display.  

 

1 Accepted Solution

Avatar

Correct answer by
Community Advisor and Adobe Champion

Yes, I do segments like that frequently... where I will create a segment such as:

 

Visit Level

    event x exists

 

OR

 

Visit Level

    custom link equals "form x submitted"   (you can create segments for each form separately for comparison)

 

OR 

 

Visit Level

    page contains "thank you"

 

Or whatever criteria I need to get all the pages back for visits that do "something"

 

(This will get me all the pages in the visit)

 

Or I will create Hit Level segments to pull out specific actions. (or some combination of these)

 

Note: Make sure that you test these out thoroughly to ensure that the data being returned really is what you expect...  you don't want to mis-report this, then have to go back months later with corrections.

 

 

In your case, still having an explicit "Form Submit" event (on the form) will allow you to see what pages are submitting the form in the context of the visit... 

 

Now for "CR" on your form, knowing which form is shown again will be easier if this is coded onto the page, rather than trying to calculate it... While not forms, we have "dialogues" that appear based on different criteria, so I can't just look at "Page X" and know that it has "dialogue A" - so I actually code in impression data (our developers tell me via data layers what is shown on the page) so that I can trigger contextual event data for "impressions".

 

So when I use my impressions metric, I can correlate to my URL to see how many times each dialogue is shown. I am also tracking the "CTA" clicks on these dialogues with another event.

 

This seems very similar to your form usage...  now, because our site is complex with many different dialogues (and multiple dialogues per page), I actually use the s.product notation (using a unique category so that I can isolate my dialogues from other s.products values) but in this way, I can use a single impression event, a single click event, and use merchandising eVars to tell the dialogues apart along with their A/B/C etc variants  (since I may have A variant for Dialogue X, and B Variant for Dialogue Y on the same page)

 

However, processing the data can get tricky due to the way Products works, but it means I can keep my variables and events minimized.

 

View solution in original post

9 Replies

Avatar

Community Advisor and Adobe Champion

Are you tracking your "form submits" based on users landing on the thank you page? 

 

I generally have specific tracking integrated with the form, on form successfully submitted, track an action on the page where the form resides. This will also prevent over tracking if the user refreshes the thank you page, or navigates back to the page using their browsers back button later on in the journey.

 

Then you wouldn't need to try and get the form page as a backwards lookup from the thank you page to the form page?

Avatar

Level 4

We are in the process of making our form submission data more refined as you mentioned, but that still doesn't address the issue i'm trying to solve.  Even if we had form start, complete, and error data, we would still have issues seeing what URL's earlier in the journey have an impact on those metrics. 

 

At this time, if I want to see that, I need to create a "visit" based segment with either a specific URL or a group of URL's to see the impact those pages have on Form Submits or  CR metrics.  

 

to illustrate this, I picked 4 pages.  On the top is the raw dimension item for each URL.  You can see visits, but not the impact to Form Submits or CR.  On the bottom, you can see the segments of the same URL's.  The only difference, is that they are "visit" based.  You can see in the bottom table there is data for Form Submits and CR.  

 

It would be tedious to do this for all of the 1000's of pages we have.  

 

Damonwhall_0-1666898775899.png

 

Avatar

Community Advisor and Adobe Champion

Right, but do you have a set of specific forms? I assume you don't have 1000 forms.

 

You could create a segment per form submit (form 1, form 2, etc)... 

 

Have you considered using a flow visualization? That could show you the page with the form submit to the resulting thank you, or you could look at the pages leading to the form with a few clicks.

 

There may be other ways to visualize the data, I am coming in new to your use case and design, but I will keep helping until we can streamline your process

Avatar

Level 4

We soon will have form specific dimensions (aside from individual thank-you pages) that will allow the forms to be grouped into classification types.  Then, we can do as you are suggesting using the form as the end point.  

 

But it still doesn't allow this same information to reside in a simple table.  

Avatar

Community Advisor and Adobe Champion

If you can use custom events, you could use custom attribution (rather than setting up segments)? Sadly, default metrics like Page Views, Visits and UVs don't allow for custom attribution?

Avatar

Level 4

I like this possibility, however, we are already using an eVar to define URL (to bypass the 100 character limit issue).  This is a pageview based eVar.  Are you saying that we would create one more additional eVar that is "visit" based (or retains for the whole visit)?  

 

Avatar

Community Advisor and Adobe Champion

Actually no, I am suggesting that in a future state, you would have a custom event for the form submission (you can use either custom link value, or a prop or eVar if you so choose to classify which form).

 

In your report, if you pull in the custom event (to pair with your existing URL eVar), you can change the attribution to linear or participation, and ALL the URLs for the period selected should auto populate. Or create one segment for visit contains "eventx exists")

 

 

You can use that same event with the standard attribution specifically for your Form Submission.

 

The single segment may be better, and you can create segments on custom link if that's what you use, to separate all the forms from one another (either an initial breakdown, then break down the urls  - or to use as dropdown control to switch the data in the panel for each form)

Avatar

Level 4

Hello @Jennifer_Dungan , 

 

I think we would not want to alter the event to be participation based or linear based.  But you are saying that even if we didn't define the attribution, we can simple make a segment that is "event 'x' exists" and apply tha to the table or panel?  And then we can see all URL's in the rows and the metric as a column.  Correct?  

 

will this also work with cohort tables as well?  

 

I think that would work if this is what you are saying (I will not be able to test this until a week or 2).  

 

And to confirm, this will only work where you have defined a numbered event to occur.  This will not work for manually created metrics correct?  

Avatar

Correct answer by
Community Advisor and Adobe Champion

Yes, I do segments like that frequently... where I will create a segment such as:

 

Visit Level

    event x exists

 

OR

 

Visit Level

    custom link equals "form x submitted"   (you can create segments for each form separately for comparison)

 

OR 

 

Visit Level

    page contains "thank you"

 

Or whatever criteria I need to get all the pages back for visits that do "something"

 

(This will get me all the pages in the visit)

 

Or I will create Hit Level segments to pull out specific actions. (or some combination of these)

 

Note: Make sure that you test these out thoroughly to ensure that the data being returned really is what you expect...  you don't want to mis-report this, then have to go back months later with corrections.

 

 

In your case, still having an explicit "Form Submit" event (on the form) will allow you to see what pages are submitting the form in the context of the visit... 

 

Now for "CR" on your form, knowing which form is shown again will be easier if this is coded onto the page, rather than trying to calculate it... While not forms, we have "dialogues" that appear based on different criteria, so I can't just look at "Page X" and know that it has "dialogue A" - so I actually code in impression data (our developers tell me via data layers what is shown on the page) so that I can trigger contextual event data for "impressions".

 

So when I use my impressions metric, I can correlate to my URL to see how many times each dialogue is shown. I am also tracking the "CTA" clicks on these dialogues with another event.

 

This seems very similar to your form usage...  now, because our site is complex with many different dialogues (and multiple dialogues per page), I actually use the s.product notation (using a unique category so that I can isolate my dialogues from other s.products values) but in this way, I can use a single impression event, a single click event, and use merchandising eVars to tell the dialogues apart along with their A/B/C etc variants  (since I may have A variant for Dialogue X, and B Variant for Dialogue Y on the same page)

 

However, processing the data can get tricky due to the way Products works, but it means I can keep my variables and events minimized.