Page tree
Skip to end of metadata
Go to start of metadata

The concept of usage metrics was well described by Antti:
initiative, stories.

There was also a GF presentation:
https://magnolia-cms.zoom.us/recording/share/B9nUqW9cQxZh8yyKcA2V3BimqbxSpCu-Ae_mQ8_m7sGwIumekTziMw?startTime=1550829720000

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 &
EE.

Main change

An instanceUuid is now assigned to the /server node.

This node also contains the boolean property usageMetrics, which is where the
admin’s decision on whether to send data to us is stored.

UI changes

magnolia-usage-metrics

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.

Privacy notice

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
early.

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
is there.)

Once the user clicks the pop-up, his consent is stored in the profiles
workspace: /<username>/hasAckedPrivacyNotice=true

Open questions

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
both reports.

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.

  • No labels

9 Comments

  1. Our reasoning was that if it was inside of UI rather than in an external JAR, people might be less likely to remove it.

    UI dependency to an external module would do the trick as well wouldn't it?

    My biggest concern is that we might reveal some issues after the release when people start using it and it would be much quicker rerelease a small module than whole UI.

    1. I know generally anything can and will go wrong. But in this case, what risks do you see in an optional POST request with a couple of text fields? If it works during our inhouse QA, I don't see what would make it fail externally, outside than instances completely cut from the network.

      1. From the experience with our integrations, usually different kind of network issues as those we can hardly test in house.

        E.g. we needed to change or expose configuration for different kinds of connections settings as timeouts.

    2. My research into the topic did not include how data collection is typically packaged – part of core vs. separate module. You could check how Atlassian Analytics is packaged inside JIRA and Confluence.

      Regarding module lifecycle, I can see the benefit of us being able to release new versions independent of a DX Core release if the module has a bug.

  2. I do agree that in case of major issue, it would be a bummer that we'd have to do a complete Magnolia just for that.

    On the other hand, I still can't see what that issue would be: networking will be provided by AWS, and to them a production instance is 2 or 3 availability zones minimum. We only have a testing instance in Europe for the time being because we are going to get very little data in the beginning. But in time, we could switch to production, and get really good network for any Magnolia instance in the world.

    Now, admitting we release and there is an issue with shaky network regardless of AWS's infrastructure. Even if instances can reach us only one day out of two, or even one day out of seven, we would still be getting valuable info. We could start working with that and wait for the next release cycle to make an improvement.

    And now finally, admitting we have usage metrics as a separate module, and something gets broken badly. How many clients running Magnolia in production would risk an upgrade for an individual module that is only supposed to help us?

    1. Roman Kovařík what if we made the REST call asynchronous? Then, really, nothing could go wrong.

      1. It's scheduled so it's already asynchronous, isn't it?

    2. Anything could go wrong (smile)

      What if there is/will be a bug and and the connection will be established regardless withdrawing the consent?

      bq. I still can't see what that issue would be: networking will be provided by AWS

      It could be a problem on their network, doesn't matter how good our infrastructure is. 

      bq. How many clients running Magnolia in production would risk an upgrade for an individual module that is only supposed to help us?

      It's more about a blocking issue for them. So they would want to update anyway. We would probably release webapps/bundles but at least without a new UI beast.


      1. Oh I see, so the module would be there so we can legally say 'we fixed it', eventhough only a small fraction of people would actually install the bugfix release.