Hi Folks,
I have a website where the one of form submit event hits is sent to the Adobe Analytics server. However, we only pass the variable value with form-submit, but no events to Adobe Analytics.
This is the existing implementation, and It has been implemented in this way for some other purpose.
The requirement is to find the number of total forms submitted against different dimensions like campaigns, etc.
Basically, to sum the form-submit dimension occurrences against different dimensions like campaign.
to create a report on this, I created one calculated metric that counts the occurrences of the segment, and the segment only considers the hits where the form-submit variable is captured.
additional note form-submit variable is a prop
I have verified that the calculated metric is working fine.
But just wanted to confirm, Is this the correct approach of counting form-submit in the report?
Is there anything that can hamper this calculation like (low traffic)?
I know that count_distinct can be used, but I need an exact count.
below is what my calculated metric looks like, and the segment is at HIT level where the prop value is the form-submit
Thanks,
Nitesh
@Jennifer_Dungan @yuhuisg @Andrey_Osadchuk @PratheepArunRaj
Solved! Go to Solution.
Topics help categorize Community content and increase your ability to discover relevant content.
Views
Replies
Total Likes
Ok, so your prop could be holding values like:
And you only want the counts for "form submitted"?
In which case, your calculated metric can just be the occurrences metric with either a standard or on the fly segment (like what you have)...
There's a lot blanked out in your original screenshot, so I assume the segment is correct and not causing unnecessary calculation..
But understanding now that the prop is multi-use helps give context to what you are doing.
Depending on how many unique values you are collecting in your prop will be the determining factor on if low traffic would have any impact, but if the form submit is a standard value like "form submitted" (or whatever value you are using) the changes are good that it should avoid the dreaded low traffic issue.. If you have multiple forms in use, or are passing multiple unique strings ("form 1 submitted", "form 2 submitted", etc) you run a slightly higher chance of hitting low traffic (again dependent on how much your prop is being used for and how popular all your variants are).
But based on what I can see of your calculated metric, I don't see anything inherently wrong (again assuming your segment is the correct logic).
If you are worried about potentially hitting low traffic, you could create a table to check the variations of the prop returned by that segment you are using in your calculated metric... if you notice that forms are missing, then it might be that they are hitting low traffic, or not used... you will have to determine which of these could be the impact.
Views
Replies
Total Likes
So the prop is set with some value on the form submit, and that is it's only use? Or maybe the prop is used for other things, but with a different value?
i.e. prop1 = "form submitted"
Right?
Props do not maintain or carry forward values... the simple "occurrence" metric with your prop is the count of form submits (since a form submit will not be a page view, but an action)... you don't need a fancy calculated metric for that.
Prop1 Occurrence
form submitted 356
the 356 is the number of times your form was submitted.
If you need to know the number of times the form was submitted by a Unique Visitor, again, you can just natively use the UV metric with your prop:
Prop1 Occurrence Unique Visitors
form submitted 356 285
Hi @Jennifer_Dungan,
Thank you for your response!
I do use that same prop variable for other purposes as well with different event details.
below is what the report expected to look like
Campaign | no. of forms submitted
daily_newsletter | 10
weekly_updates_email | 5
no. of forms submitted is fetched using calculated metric I mentioned in my initial post description, and that is returning perfectly correct numbers.
I am bit concerned about How the calculated metrics I have configured.
Thanks,
Nitesh
Views
Replies
Total Likes
Ok, so your prop could be holding values like:
And you only want the counts for "form submitted"?
In which case, your calculated metric can just be the occurrences metric with either a standard or on the fly segment (like what you have)...
There's a lot blanked out in your original screenshot, so I assume the segment is correct and not causing unnecessary calculation..
But understanding now that the prop is multi-use helps give context to what you are doing.
Depending on how many unique values you are collecting in your prop will be the determining factor on if low traffic would have any impact, but if the form submit is a standard value like "form submitted" (or whatever value you are using) the changes are good that it should avoid the dreaded low traffic issue.. If you have multiple forms in use, or are passing multiple unique strings ("form 1 submitted", "form 2 submitted", etc) you run a slightly higher chance of hitting low traffic (again dependent on how much your prop is being used for and how popular all your variants are).
But based on what I can see of your calculated metric, I don't see anything inherently wrong (again assuming your segment is the correct logic).
If you are worried about potentially hitting low traffic, you could create a table to check the variations of the prop returned by that segment you are using in your calculated metric... if you notice that forms are missing, then it might be that they are hitting low traffic, or not used... you will have to determine which of these could be the impact.
Views
Replies
Total Likes
Hi @Jennifer_Dungan,
My segment is pretty straightforward, and it will only return a single value for a specific form.
Thanks a lot for your help on this post. It helped me a lot to get confidence in this workaround approach.
Thanks,
Nitesh
You're welcome... sorry it took a while for us to get here, but I am glad we got there eventually
Views
Replies
Total Likes
As a workaround, your approach works (subject to any clarifications that you have with @Jennifer_Dungan ).
However, as a correct implementation, it's not ideal. You should set a success event to measure every form submission. That is really the way to measure conversions in Adobe Analytics.
If you have several forms, you can set the success event with an eVar to track both the form submission and the form name respectively.
Agreed, having an isolated event specific to your form is a much better implementation.. but that doesn't help historical data.
To help determine the count from what's already been collected, I will continue to help with this.. but fixing the tracking will make this much easier going forward (on that I 100% agree with @yuhuisg)
Views
Replies
Total Likes