jeremied / analytique Goto Github PK

Merge all google domains into one, for example.
Also maybe use a favicon in the data point lists? Could allow for some fun stuff in the future.

Google:
google.com, google.ca, google.fr, google.nl, etc.

Facebook:
l.facebook.com, facebook.com, m.facebook.com, etc.

Instagram:
l.instragram.com, instagram.com, etc.

Pinterest:
pinterest.com, pinterest.es, etc.

Perhaps in a wiki-style manner, maybe on GitHub.

Including Get Started, Contributing, as well as full code docs.

So that is doesn't change too often and avoids arbitrary floats

Would benefit from a graph view instead of data point list.

• Config template in the repo, that is duplicated to create the config file if none is detected.
• Config for beacon (homebase URL and data collected, screen breakpoints from config)
• Check for config / valid config on start and log errors / instructions.
• Config ideas
  • First day of the week
  • For graphs:
    • Display trend line
    • Display average

EN/FR by me. Infrastructure for others but I won't do anymore.

Code is in English.

Alternate stat: Exit rate (Number of exits ÷ number of views for page)

Potentially means that the beacon must wait for an unload event before sending.
To keep using the sendBeacon API, a mechanism needs to be implemented to delay sending for an arbitrary amount of time.

Or, maybe, additional data is completely separate from the base view data. The additional data would be sent separately from the view and would thus require separate counting. The view data would only contain data inherent to the browser and view event. Things like button clicks and game scores and behaviour on page wouldn't be associated to a session.

UTM solution as well. https://plausible.io/blog/utm-tracking-tags
But I would like to overhaul how we think about these. I would also like to get rid of the "UTM" name. It should be explained clearly somewhere though.

Like Time of Day, would probably benefit from a graph view instead of just a data point list.

I'm dumb and forgot that sometimes sessions will be intertwined and thus the algorithm fails to aggregate views.
The views → sessions algorithm needs to be refactored to take that into account.

Targets are WebKit, Chromium and Gecko on Windows, macOS and Linux.
Mobile platforms are not really targets, at least for now, although some minimal testing might benefit security.

With comparison to previous stats? (+5)

It shouldn't divide the page views for the same path, but it could still be interesting to keep the fragment somewhere. Usage will vary a lot depending on the website so it should be nicely configurable.

It's probably a good idea to have features that allow extracting, deleting and ignoring beacons coming from specific IP addresses.
It might also be important to remind users of Analytique that they should tell their audience that they are tracking them in a Privacy Policy. ("Netiquette")

To allow potentially arbitrary characters.
File names are currently limited to [\w-@].

The data might go on left of the fold for example and you could simply scroll the view.

There might also be a + button that appears when hovering the X axis label that lets you zoom out. For exemple, changing "12 dernières semaines" to "24 dernières semaines".

Maybe with a simple scroll container? Maybe with an icon to indicate when there is more data? Use Scroll snap points?
Otherwise it could be an icon button that unwraps more data points / activates the scroll container.

That means the calendar UI needs a way to select multiple continuous days, probably by dragging.

Slide/scale the graphs whenever possible? Tick numbers (at least the big ones) up or down?

• Use an iterator function instead of monthRange. Simply iterating a plural JDDateRange will yield all unit-mode dates covered.
• Allow adding and subtracting any units to any value?
• Simpler bridging of JDDate and JDDateRange. If implementing from and to with a parameter to choose the unit to return, those two getters could be used on JDDates as well and they would thus be mostly the same.
• Use "start" and "end" instead of "from" and "to"
• The mode converter by default does strict converting (ignoring "current" ranges"). You can use the current behaviour by specifying "stayCurrent" or something.
• Support negative years like this: "-0056-01-20", "-0056-01", "-0056-W03", "-0056".

ref: https://developer.apple.com/documentation/swift/range

Using config files for all patterns.
Ideally with a main/default/master config, that can be overriden/added to with origin-specific config.

AnalytiqueModule could be an object containing most of the fields that AnalytiqueListModule could inherit from. The drawing function would be reused for most modules but could be overriden.

I think modules should be their own sort of objects.

{
  "type": "list",
  "sessionKey": "referrerOrigin",
  "statsKey": "referrerOrigins",
  "basis": "sessionTotal",
  "fromView": function,
  "fromSessions": function,
  "keyTransform": _identity,
  "data": {
    "categories": {
      "Google": [ "google.com", "google.ca", "google.fr", "google.nl" ]
    }
  },
  "strings": {
      "title": {
      "en": "Origines",
      "fr": "Origines"
    },
    "description": {
      "en": "Number of sessions per referrer, when acquisition was by reference.",
      "fr": "Nombre de sessions par origine, lorsque l’acquisition s’est faite par référence."
    }
  },
  "config": {
    "useGroupsInOverview": true
  }
}

The fromView function takes in a view and outputs a session metric.
The fromSessions function takes in a sessions container and outputs a stats metric.

strings and data are both variable objects that contain static data that other code in the module can use. It is meant to avoid constantly putting in and out of memory larger pieces of data. strings is for human-readable text used in the rendering of the module, while data is mostly used during processing of stats data.

Could be a secondary button that opens a contextual menu to select a range to compare against. That range would then be displayed alongside the main range. Slightly transparent in the graphs, and maybe using delta ± for numbers.

That means updating the read me and I guess making sure there are no sensible information anywhere.

I think we need three forms:

• The canonicalForm (old shortForm), which is the internal canonical form that contains no spaces. It's never meant to be displayed to the end-user.
• The specialForm, which is the short, human-readable version that can take many forms. "Aujourd'hui", "Hier", "28 derniers jours", etc. If no special case apply, it uses the niceForm.
• The niceForm is the human-readable, exact version that always uses days.
  • "day": 28 août 2022
  • "days": 27 au 29 août 2022, 30 juillet au 29 août 2022, 25 décembre 2021 au 29 août 2022, etc.
  • "week": Semaine du 20 au 26 juin 2022
  • "weeks": → like "days" mode
  • "month": Août 2022
  • "months": Août à Septembre 2022, Décembre 2021 à août 2022
  • "year": 2022
  • "years": 2021 à 2022

The niceForm could be displayed with the origin selector when different from the specialForm.

Only "days" mode is missing.

Central and invisible API for routing and serving data, and possibly console output?

That I could reuse for all Node web projects.

A map view for the countries module could eventually be an option, but I don't think it's interesting enough on its own to be a priority. It's also not very interesting for most small-scale websites, which won't really have an international audience anyway. So it should be an option.

There might be nothing to optimize for now, but at least I'd have data to work with.

• QA pass

Hold and drag one bound to move it specifically?
Change the hold thing to click once per bound and hold and drag to move the selected bound? Like Google Analytics?

In a long long time, it might be nice to have a testing environment, because as more and more features are added to the analytics engine itself, the harder it is to actually measure their accuracy.

Some simple sanity checks could include testing that beacons are received and stored properly, checking that sessions that overlap in time are correctly reordered in the aggregation phase, checking that exclusions in the config are properly ignored (countries, IPs and bots), etc.

Refactor the Cities module to include all countries by default. Setting to only determine city for some countries.
Maybe it's not even necessary now that we got the filter working great. The idea at the start was just to mitigate the calls to the slow ipinfo.io API. But maybe it's not worth it anymore, especially since the city could be requested at the same time as the country, not taking any additional time.

So that it can be reused in both, and possibly more projects. I could serve CSS from one central location I guess. With optional components.

Everything should use SCSS, perhaps with some modules.
Text styles should be separated from semantic elements, and applied contextually or explicitly using class names.
Same for form components, their style should be decoupled from their semantic elements.

Make a big test page to test all components.

It might be a good idea to have a test page for some critical components like JDDate. It could be a simple page with some programmed tests for all functions and outcomes. Because you never know when an untested edge case is gonna affect something down the line.

• Basic calendar stuff like length of key months, length of key years, day of the week, etc.
• Date rendering in all forms, including natural language
• Parsing
• Mises en situation, par exemple: Produire un range de l'année courante + 2 semaines avant et 2 semaines après. (En convertissant .thisYear() en jours, puis en déplaçant le début de -14 jours et la fin de plus +14 jours.