Implement basic conversion counters

[danieliser]

Similar to how we offer simple open tracking for popups we can add conversion tracking too.

• Add [popup_conversion] shortcode.
• Track integrated form conversions.
• Integrate with Actions/Events system.
• Prevent duplicate tracking of same conversion (cookie or localStorage).
• Allow Popup Analytics to extend core for more detailed data collection & reporting.

[fpcorso]

@danieliser , do you think this would then evolve to be similar to Ahoy? Showing conversion counts in the Popup list and maybe conversion stats in our analytics extensions?

Should we aim for high-standard here or do a smaller MVP first and then slowly evolve it?

Either way, I think getting in more data on conversions is absolutely the right direction for us, especially knowing our longer-term plans.

[danieliser]

@fpcorso Its Ahoy on sterioids. Ahoy lacks in the ability to detect non integrated conversions, same for PM currently. This goes a long way to alleviating that constraint going forward. Any thank you page can be a trackable conversion.

That said now that I've said that out loud I can see we also need to probably set some cookies or localStorage so that a user isn't tracked more than once on subsequent refreshes.

[fpcorso]

@danieliser So, the big question is if this should be in core or if this should be in Popup Analytics (or perhaps another extension?)? I think you made a valid point over in #429 about if we are positioning ourselves as a conversion tool that it makes sense to add some basic conversion tracking into the free version.

Would this be built into the call-to-action system you want to port from Ahoy or would this be completely separate from that?

[danieliser]

@fpcorso They would be tied together for sure I would think. CTA's are effectively types of conversions, if we control the CTA's we control the flow and ability to accurate track them as well.

Each CTA will have a different mechanism, for most a conversion === click on the button.

That said for popup analytics we also need to discuss this concept. What is a conversion for a given popup. Just like ahoy, is conversion a click on the button that adds items to cart, or the purchase itself. In which case what do we track for the click on the button (which is currently considered the conversion).

Conceptually that is the only thing we need to really work out is the semantics of what a conversion is and how much value it was worth.

[fpcorso]

@danieliser Okay, I'll bump this to 1.12 for now, and then at some point soon we can revisit to identify the exact nature of this.

[fpcorso]

@danieliser We need to come back to revisit this one too. Would we build this at the same time as the CTA's in #848 or is this something we could layer on top afterwards, possibly when building the events manager in #348?

Would the CTA fire the conversion or would this system handle all conversion data which would mean CTA's need to pass data to this system?

In the current version of Popup Analytics, the user sets what is a conversion in their popup. Would we tie this into that or replace that with this? In that case, should this be inside Popup Analytics?

[danieliser]

@fpcorso - Great conceptual questions.

1. Could be added independently.
2. CTA would fire a conversion tracking event. Some via JS over Beacon, others via PHP. Detected form submissions would fire the event as well.
3. Both, Popup Analytics piggy backs on core's event system and just overloads the core functionality. So in core it would store a simple counter, in PA it would track individual events over time.

[fpcorso]

@danieliser Can you breakdown what we would need to do to create this? Would this just be us adding a new event type to the analytics system (https://github.com/PopupMaker/Popup-Maker/blob/master/classes/Analytics.php) and then display that number somewhere in the admin for the popups?

What would need to be built to "trigger" this event? Would we add a setting per popup, like in Popup Analytics, where the admin would define what the conversion is (e.g. form submission, popup close, etc...)?

[danieliser]

@fpcorso - Yea the way the counters are built they just take an event name and do the rest.

1. Conversion is already built in as a valid type: https://github.com/PopupMaker/Popup-Maker/blob/master/classes/Analytics.php#L74
2. We do need render conversion data in the admin metabox, BUT, this might already be there from the Ahoy -> PM port before, it was likely commented out as I wasn't ready to add that.
3. Lastly we need to tie the existing form submission callback in both JS & PHP to track it. JS will use the beacon method and for PHP there are helper functions to increase event counts for specific popups already, if not globally you can use the ones on the PUM_Model_Popup object.

[fpcorso]

@danieliser Since css classes in the main table probably aren't used each time someone comes to this page but they may look at the numbers, should we move that column to be after the opens and conversion counts?

Current columns (with title and date hidden by default):

[fpcorso]

@danieliser In addition to the question above, should we automatically say a form success in our popup (either our own forms or a form builder we integrate with) or should we let them designate what a conversion is?

In the old version of popup analytics, we had this:

Should we add this same meta box for this new conversion counter in core? If so, do we use the same options? So, auto would count any form submitted as a conversion or they can select buttons or links too?

Of course, once we add call-to-actions, there may be other forms of conversions, so what would be the best way to handle determining what a conversion is?

Or, since almost all popups should only have one main conversion, do we just automatically count them as conversions for any of them? So, if there is a form submitted inside, it's a conversion and if there is a call-to-action button (e.g. to add to cart or apply discount), its click is a conversion.

I like the strategy of detecting and handling the whole process within the code as opposed to adding yet another thing for the admin to figure out.

[danieliser]

@fpcorso - Yea that option shouldn't make it to core. Just detect them and count it haha.

If we get complaints we will add a filter or something that lets them disable it ad-hoc.

Not concerned about order of columns though, your choice.