There was also a GF presentation:
The goal of this page is to describe the actual implementation that we ended up
doing for 6.1 (other streams also if possible) after we discussed what was
possible with the lawyer and different developers.
Our mindset with this first version was to get a sense of what people are
running. Even if the data is imperfect, it will help us tremendously.
Usage metrics will be included in the empty webapp, therefore affecting CE &
instanceUuid is now assigned to the
This node also contains the boolean property
usageMetrics, which is where the
admin’s decision on whether to send data to us is stored.
A new UI submodule named
magnolia-usage-metrics was created. Our reasoning
was that if it was inside of UI rather than in an external JAR, people might be
less likely to remove it.
The command can legally be on by default after checks with our lawyer.
Usage metrics can be turned on as long as the end user is made aware that some
tracking is happening (eventhough data is anonymous and isn’t even about him).
The notice was therefore made part of Admincentral so that it can be shown very
The other solution would have been using the
MessagesManager to register a
message, but that would have been too subtle. (Only a ‘1’ to indicate a message
Once the user clicks the pop-up, his consent is stored in the
Author vs. public
This is one of the tricky topics that we chose to exclude out of this version.
There’s the problem that some author instances will not be able to reach us.
For this we could have the author instance publish the report to the public
before it is sent to us. But then there would have to be some aggregation of
In any case, usage metrics will send whether the report comes from a public or
author instance. So when we start to get some data, we can make sense what step
to take next.