How to track Events with Google Analytics from PHP

[bernhard]

As the topic title says I want to share an idea I came up today: Why not track my module installations via Google Analytics?

Very simple one, but huge potential and maybe somebody else has not thought of this possibility yet. It can also be used to track sent emails, submitted forms, log errors, whatsoever...

$http = new WireHttp();
$http->post('http://www.google-analytics.com/collect', [ // Make sure to use HTTP, not HTTPS!
  'v' => 1, // Version
  'tid' => 'your-tracking-id', // Tracking ID / Property ID.
  'cid' => 555, // Anonymous Client ID.
  't' => 'event', // hit type
  'ec' => 'myEventCategory', // category
  'ea' => 'myEventAction', // action
  'el' => 'myEventLabel', // label
]);

You can test your setup here: https://ga-dev-tools.appspot.com/hit-builder/

Happy tracking

[Robin S]

15 hours ago, bernhard said:

Why not track my module installations via Google Analytics?

Would you mind clarifying what you mean here? Are you saying the PW modules you share here with the community might start sending data to your Google Analytics account?

[bernhard]

7 hours ago, Robin S said:

Would you mind clarifying what you mean here? Are you saying the PW modules you share here with the community might start sending data to your Google Analytics account?

Sury, I'm only tracking installations and uninstallations of the RockForms module at the moment: https://gitlab.com/baumrock/RockForms/blob/master/RockForms.module.php#L13-39

[Zeka]

Actually, I think that is a great idea to track interest for modules, but it would be nice to have this feature and tracked information more centrally and open, so a potential user can see 'popularity' of modules that it gonna use. 

[bernhard]

7 minutes ago, Zeka said:

Actually, I think that is a great idea to track interest for modules, but it would be nice to have this feature and tracked information more centrally and open, so a potential user can see 'popularity' of modules that it gonna use. 

Same here. But as long as this is not implemented I'll do it on my own for my own modules

[Robin S]

@bernhard, you are of course free to put whatever you like into your modules. However, having your modules "phone home" like this discloses data that users may not want shared. At the minimum the website URL is disclosed. Not every site that exists on the internet is intended for public access. There are things like staging servers, and probably a whole range of other sensitive sites.

My personal opinion is:

1. I think there should be a very clear and prominent statement so that users know that the module will send data to a third party, and what data will be sent. And I'm not sure that only a notice in the module readme would be satisfactory because users might download via the PW admin without seeing the readme. And if you start adding this to existing modules that didn't have it before it could pass by unnoticed when the module is updated. Basically there needs to be informed consent before data is sent, and probably also a privacy policy.

2. I think this crosses a line that shouldn't be crossed, and sets a dangerous precedent that if followed by others could be harmful to the PW project/ecosystem. There is a huge amount of trust placed in third-party modules by users. Modules can potentially access any website data. The very notion that a module phones home erodes trust. We don't want to create a sense of unease where every time a user contemplates installing a module they feel like they ought to comb through the source code to see what the module might be disclosing to a third party.

In the bigger picture, I'd like to see PW get a reputation as being a system suitable for large institutional and government clients. Here in New Zealand, SilverStripe is in the enviable position of being seen as the go-to system for government websites. I think PW should be competing in this space. But government and institutional clients won't touch PW with a pole if there is a perception that there are privacy issues with modules in the PW ecosystem.

I think the right way to track software popularity is by counting downloads, not phoning home. Sadly GitHub and GitLab don't provide useful tools for this, but that is another discussion.

[szabesz]

@bernhard and do not forget GDPR, e.g.:

https://www.willows-consulting.com/gdpr-for-ecommerce/

• Include a GDPR compliance line
• Specify what information you collect and store from website visitors. ( e.g. ip addresses, device information, access information, cookies, visit duration and tracking, mouse and swipe actions, email, phone, name, address and billing addresses )
• Specify who you has access to this personal data. (E.G. you, mailchimp, google, salesforce etc )
• Specify the contact details of the assigned Data Protection Officer in your organisation
• Specify how to lodge a data subject access request.
• Specify how long you hold personal information.
• Get their clear consent to process the data.

Info on the number of installations seems to be a little bit of a different topic but – as Robin said above – how can the site's superuser decide?  I think it is best to treat any data collection in the sense of GDPR as it is all about transparency in the first place.

[bernhard]

Hi Robin and szabesz,

I was actually expecting that something like this would come up. I'm happy about your feedback  

11 hours ago, Robin S said:

discloses data that users may not want shared

I'm not sure about that. I can actually only see the number of Events that occured. Nothing else. No visitor information at all. The request is sent with an anonymous client ID, so there is really no data connected to anybody. No cookies are set. Nothing. Basically it's just a counter.

11 hours ago, Robin S said:

I think there should be a very clear and prominent statement so that users know that the module will send data to a third party, and what data will be sent. And I'm not sure that only a notice in the module readme would be satisfactory because users might download via the PW admin without seeing the readme. And if you start adding this to existing modules that didn't have it before it could pass by unnoticed when the module is updated. Basically there needs to be informed consent before data is sent, and probably also a privacy policy.

I partially agree. I would love to have some kind of pre-screen before a module is installed. Maybe I'm wrong, but I think at the moment we only have the "summary" statement that is shown before installation? It does not support HTML though. I think it would nice to have the possibility to place some statements before installation and also before updating a module that the user must accept. This could be nice in several situations. The user could check a box to agree to data submission, the user could be informed about breaking changes that may be installed with an update, we could show a donation button etc.

11 hours ago, Robin S said:

I think this crosses a line that shouldn't be crossed, and sets a dangerous precedent that if followed by others could be harmful to the PW project/ecosystem. There is a huge amount of trust placed in third-party modules by users. Modules can potentially access any website data. The very notion that a module phones home erodes trust. We don't want to create a sense of unease where every time a user contemplates installing a module they feel like they ought to comb through the source code to see what the module might be disclosing to a third party.

I don't agree with you here. Actually I do think it is quite the opposite. Trust in ProcessWire is for sure a good thing. In its security, in its features, in its future. But I do not think, that (blind) trust in 3rd party modules is good. As you said, any module author can basically do anything within the instance where it is installed. This may not be obvious especially to unexperienced users. So I think actions/discussions like this support the ecosystem and do not harm.

But again, I agree that a "feature" like the install/uninstall tracking should be stated more prominent. BTW: I have 26 likes and 0 installs for RockForms so far, so nothing happened until now  

[szabesz]

22 minutes ago, bernhard said:

I would love to have some kind of pre-screen before a module is installed. Maybe I'm wrong, but I think at the moment we only have the "summary" statement that is shown before installation? It does not support HTML though. I think it would nice to have the possibility to place some statements before installation and also before updating a module that the user must accept. This could be nice in several situations. The user could check a box to agree to data submission, the user could be informed about breaking changes that may be installed with an update, we could show a donation button etc.

Yep, lots of us have been waiting for something like this for quite a long time: 

 

So this "changelog" feature could be boosted with these new ideas of yours, too. (like "user could check a box to agree to data submission", etc...)

[bernhard]

Thanks szabesz, I support your request and liked + commented it on github

[bernhard]

PS: @Robin S

I don't think there is a real "eco"system around pw modules by the way. There are some commercial modules, but nobody (except the authors) knows how many people are using them. I don't think this is something that attracts other developers... And it makes it hard for us to estimate if developing/supporting a module is worth the effort (and time) or not. It makes it even harder when it comes to commercial modules. Which pricing should one choose? 10 hours of work devided by 1 user is something totally different than devided by hundreds... Tracking the interest in a module could maybe bring some light into that.

[adrian]

Interesting discussion here

I agree that the PW really needs to track module installs / uninstalls to give module authors some idea of module usage. I feel like it should be as simple as a call from the install() and uninstall() methods. These numbers should be displayed in modules directory - easy and transparent!

As for the approach that @bernhard has taken. I have to admit that I thought about the same approach a little while ago, but thought it might illicit a response like @Robin S's. I am certain that in Bernhard's case it's all above board, but I guess you never know what module authors could potentially start tracking. 

Something to think about is that the PW core unintentionally does something vaguely similar already - take the links to Page, PageArray and NullPage (when editing a Page Reference field) as just one example.

These links are to processwire.com which means that if you click on these from your site, the google analytics for processwire.com will show the domain of your site in the "Acquisition" section. This will include local dev domains, staging domains, etc, all because of http_referer.

I realize that in this example you have to actively click on a link to trigger the call, but it's something to be aware of if you're really concerned about keeping a domain name private.

Cheers!

 

[Robin S]

15 hours ago, bernhard said:

I can actually only see the number of Events that occured. Nothing else. No visitor information at all.

I thought Google Analytics would log the origin of the event, but I tested it and it seems that it doesn't (unless that information is explicitly passed in the event, and I trust you won't start doing that). So that makes me feel a little better.

10 hours ago, adrian said:

These links are to processwire.com which means that if you click on these from your site, the google analytics for processwire.com will show the domain of your site in the "Acquisition" section. This will include local dev domains, staging domains, etc, all because of http_referer.

This isn't true in the instances you mentioned, because Ryan has thoughtfully used the "noreferrer" keyword for the links, presumably because of the privacy concerns we're talking about here. And as a site developer you have control over referrers using the meta referrer tag if need be (in the past I have added this to the admin theme on some sensitive sites).

12 hours ago, bernhard said:

I don't think there is a real "eco"system around pw modules by the way.

By ecosystem I mean all the software associated with ProcessWire that isn't in the core. Rightly or wrongly, people's perception of a system is influenced by the third-party software associated with it. The WordPress plugin ecosystem is like the wild west, and that's a big part of the reason for WP's poor reputation as a platform for serious development.

The PW module ecosystem is as good as we make it. You're absolutely right that the onus is on the user to check what they are installing to their site. But it has been quite nice so far to have a sense of trust that the folks who are contributing modules to the PW community are taking care of privacy and security in the ways that I think everyone expects.

I completely get why developers are curious about how many installs, who is using their tools how often, and lots of other things I wouldn't mind knowing myself. I just don't think that curiosity in any way trumps the right of users to control what is being disclosed. Crossing this line to actively sending data to a third party makes me uneasy, and personally I won't be installing any modules that do this.

[cstevensjr]

4 minutes ago, Robin S said:

I just don't think that curiosity in any way trumps the right of users to control what is being disclosed. Crossing this line to actively sending data to a third party makes me uneasy, and personally I won't be installing any modules that do this.

+1

[adrian]

3 hours ago, Robin S said:

This isn't true in the instances you mentioned, because Ryan has thoughtfully used the "noreferrer" keyword for the links, presumably because of the privacy concerns we're talking about here.

Thank you for pointing this out! Sorry for not checking and making an incorrect assumption.

What about module authors who use Markdown links on the config settings page of their module, or in the ReadMe or Documentation (and you have @netcarver's ModuleReleaseNotes installed). I can't seem to find any issue on adding noreferrer etc to Markdown links.

Any thoughts on what we should do on this front, if anything?

[Robin S]

22 minutes ago, adrian said:

What about module authors who use Markdown links on the config settings page of their module, or in the ReadMe or Documentation

Yeah, it is a concern for all external links in the admin, as the referrer will leak the login URL.

It's straightforward to fix with a hook...

$wire->addHookAfter('AdminTheme::getExtraMarkup', function(HookEvent $event) {
    $parts = $event->return;
    $parts['head'] .= '<meta name="referrer" content="no-referrer">';
    $event->return = $parts;
});

...but perhaps this should be in the core admin themes.

[adrian]

8 hours ago, Robin S said:

...but perhaps this should be in the core admin themes.

Sounds to me like it should - I don't think module authors should have to worry about this. Are you interested in raising this with Ryan?

[Robin S]

7 hours ago, adrian said:

Are you interested in raising this with Ryan?

I've opened a GitHub request: https://github.com/processwire/processwire-requests/issues/172