Below is one single form. On submit button I need to capture
variable1 -> new/existing
variable2 -> reason for appointment values
variable3 -> clinician names
I don't have the liberty to use eVARS and PROPS
question:
1) using Events , in the same form can I capture these 3 variable names and it's values - if so how ?
2) Because it's in the same form - I don't think cusotm_link can be used as well. Please advice
Solved! Go to Solution.
Topics help categorize Community content and increase your ability to discover relevant content.
Views
Replies
Total Likes
If you have the resources to set an event, I do not understand why you are barred from using a variable or link tracking. As Jennifer said, you options are not great in that case.
However, IF YOU WERE able to use a variable, I would use a single variable for user-entered form data. In your example the format might be:
<formID>_reas:<option>|clin:<option>
For example: mkappt_reas:3|clin:1
The string is a concatenation of the selected options. It assumes there is a trigger for the submission of the entire form such as a submit button. Tracking the selected options as users go through the form will not work well.
The first element identifies the specific form. Following the underscore delimiter are the name value pairs for the fields and selected options in the form. Each field name-option pair is separated by a pipe delimiter.
You can use numeric ids or alpha ids or a combination (as in my example) as long as you keep with in the character counts for the evar (250) or prop (100).
Assuming different forms have different options, I would create a classification for the FromID and leave it at that. Classifying the options may be too complicated if you have a lot of different fields across multiple forms.
First off, Adobe Analytics really isn't the tool to use to capture form submission data... If you really need to store form submissions it should be held in a proper database...
With opt-outs, the ability to block web analytics with adblockers and such, you won't be able to collect 100% of the data...
Then, on top of this, you are telling us that you can't use any dimensions... so this has now gone from not ideal, to very hard.
If you can truly only use events, which are basically just counters... I suppose you could assign one event per potential value like so:
Depending on how many values you have, this will eat up a lot of your custom events, and would be highly inefficient (having to use a single event for each unique value), and trying to pull these into a report would be insane and very hard to read/use.
I believe that custom link only has a character count of 100... so I suppose if you had a small enough set of values, you could pass an small identifier to know the form, and a short form for each value.. but I don't think you can apply classifications on this field, so you wouldn't be able to split it within Adobe for readability.
To re-iterate, I think it is a bad idea to use Adobe Analytics for this purpose, and to be limited solely to events makes this a very very bad solution...
Is there a reason you are trying to implement this with events alone?
Views
Replies
Total Likes
If you have the resources to set an event, I do not understand why you are barred from using a variable or link tracking. As Jennifer said, you options are not great in that case.
However, IF YOU WERE able to use a variable, I would use a single variable for user-entered form data. In your example the format might be:
<formID>_reas:<option>|clin:<option>
For example: mkappt_reas:3|clin:1
The string is a concatenation of the selected options. It assumes there is a trigger for the submission of the entire form such as a submit button. Tracking the selected options as users go through the form will not work well.
The first element identifies the specific form. Following the underscore delimiter are the name value pairs for the fields and selected options in the form. Each field name-option pair is separated by a pipe delimiter.
You can use numeric ids or alpha ids or a combination (as in my example) as long as you keep with in the character counts for the evar (250) or prop (100).
Assuming different forms have different options, I would create a classification for the FromID and leave it at that. Classifying the options may be too complicated if you have a lot of different fields across multiple forms.
If like @RobertBlakeley said, if you can use a dimension, a list dimension might be the ideal choice... there is no character count limitation on lists (just on each item within the list)... and you can still use classifications on this...
So you could pass the entire for with a prefix per question, and the value similar to the above... using the classifications simply to split the data up (classification per question, prefix to determine which classification to send the data into, and only populating the data for readability).
Views
Replies
Total Likes