Expand my Community achievements bar.

Webinar: Adobe Customer Journey Analytics Product Innovations: A Quarterly Overview. Come learn for the Adobe Analytics Product team who will be covering AJO reporting, Graph-based Stitching, guided analysis for CJA, and more!
SOLVED

Distinct dimension count

Avatar

Level 2

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

nitesh__anwani_0-1692955448209.png

 

Thanks,

Nitesh

 

@Jennifer_Dungan @yuhuisg  @Andrey_Osadchuk @PratheepArunRaj 

Topics

Topics help categorize Community content and increase your ability to discover relevant content.

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

Ok, so your prop could be holding values like:

 

  • some value 1
  • some value 2
  • form submitted
  • some other value
  • etc

 

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.

View solution in original post

7 Replies

Avatar

Community Advisor

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

Avatar

Level 2

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

Avatar

Correct answer by
Community Advisor

Ok, so your prop could be holding values like:

 

  • some value 1
  • some value 2
  • form submitted
  • some other value
  • etc

 

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.

Avatar

Level 2

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

Avatar

Community Advisor

You're welcome... sorry it took a while for us to get here, but I am glad we got there eventually

Avatar

Community Advisor

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.

Avatar

Community Advisor

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