Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimisation des requêtes de la page des statistiques d'un contenu #6347

Open
Situphen opened this issue Jul 3, 2022 · 0 comments · May be fixed by #6349
Open

Optimisation des requêtes de la page des statistiques d'un contenu #6347

Situphen opened this issue Jul 3, 2022 · 0 comments · May be fixed by #6349
Labels
C-Back Concerne le back-end Django

Comments

@Situphen
Copy link
Member

Situphen commented Jul 3, 2022

Actuellement, on récupère les données statistiques du contenu d'une manière assez bourrine, ce qui évidemment n'est pas très performant. Pour la page des statistiques du contenu « Un zeste de Python » par exemple, on envoie une seule requête HTTP à Matomo mais elle contient 272 requêtes pour son API. Contenu de la requête et contenu de la réponse. On demande les statistiques des visites pour chaque page du contenu et pour chaque jour de la période demandée, c'est-à-dire avec une granularité importante, pour ensuite n'utiliser qu'une partie de ces données dont certaines sont agrégées.

Si on regarde la page des statistiques d'un contenu, elle contient trois parties :

  1. les graphiques « Pages vues », « Temps moyen de lecture » et « Nombre de visiteurs uniques » qui concerne le contenu dans son ensemble (on n'a donc pas besoin du détail de chaque page du contenu) et pour chaque jour ;
  2. le grand tableau avec les colonnes « Page », « Vues », « Temps moyen sur la page » et Visiteurs uniques » où l'on a besoin des données individuelles de chaque page sur toute la période (donc pas besoin d'un détail jour par jour) ;
  3. les trois tableaux « Types de référent vers ces pages », « Sites entrants vers ces pages » et « Mots-clés vers ces pages » qui concernent le contenu dans son ensemble (on n'a donc pas besoin du détail de chaque page du contenu) sur toute la période (donc pas besoin d'un détail jour par jour).

Il est donc probablement possible d'optimiser nos requêtes pour ne demander à Matomo que dont on a besoin. Voici quelques pistes de réflexion pour l'instant :

  1. Sur l'interface web de Matomo, si vous allez dans l'onglet Page de la rubrique Comportement, vous avez l'arborescence des différentes pages du site web. Au survol d'une page, il y a quatre boutons à notre disposition et le plus à droite permet d'afficher des graphiques identiques aux nôtres. (Cf. la capture d'écran en bas de ce message.) Il se trouve qu'en bas à droite du graphique, un bouton permet d'exporter le jeu de données, ce qui donne :

    https://matomo.zestedesavoir.com/index.php?module=API&format=JSON&idSite=6&period=day&date=2022-06-03,2022-07-02&method=Actions.getPageUrls&label=tutoriels+%26gt%3B+2514+%26gt%3B+un-zeste-de-python&filter_limit=100&format_metrics=1&expanded=1&token_auth=ENTER_YOUR_TOKEN_AUTH_HERE
    

    Une seule requête permet d'obtenir toutes les données nécessaire à ces graphes au lieu d'une soixantaine dans notre cas. On reste sur une date sous forme d'intervalle (date=2022-06-03,2022-07-02) avec une granularité au jour (period=day) mais cette requête utilise Actions.getPageUrls au lieu de Actions.getPageUrl et surtout utilise label=tutoriels+%26gt%3B+2514+%26gt%3B+un-zeste-de-python au lieu de pageUrl=http://... . L'encodage URL est dur à lire donc voici ce que ça donne après conversion : label=tutoriels+>+2514+>+un-zeste-de-python. On retrouve le tutoriels > 2514 > un-zeste-de-python de l'arborescence de l'interface de Matomo. Cette étiquette renvoie bien les résultats de toutes les pages qui commencent par /tutoriels/2514/un-zeste-de-python/ car si l'on souhaite seulement cette page, il faut utiliser l'étiquette tutoriels > 2514 > un-zeste-de-python > @/index (encodée comme il se doit, bien entendu).

  2. Pour ce grand tableau, on peut déjà remplacer period=day par period=range ce qui permet de ne pas avoir les détails jour par jour mais le total ou la moyenne sur toute la période. Ensuite, il faudrait regarder s'il existe une alternative à l'envoi d'une requête par page ou non. Peut-être s'intéresser de plus près à label= et à la différence entre Actions.getPageUrl et Actions.getPageUrls ?

  3. Pour les trois petits tableaux, là encore on peut commencer par remplacer period=day par period=range. Au lieu d'envoyer une requête avec segment=pageUrl==http://... par page, je pense qu'on pourrait se contenter d'une seule requête avec segment=pageUrl=^http:// où l'URL est celle du contenu. La différence étant l'utilisation de =^ (Starts with) au lieu de == (Equals). Documentation correspondante.

Il y a une autre optimisation souhaitable à mettre en place : ajuster la granularité des graphiques en fonction de l'intervalle demandé. Si l'intervalle est d'une semaine, on peut se permettre d'afficher un graphique jour par jour. Si l'intervalle est d'une année, il faudrait ajuster la granularité en conséquence (probablement à la semaine ou au mois).

Documentation de l'API de Matomo

Capture d'écran de l'interface de Matomo

@Situphen Situphen added the C-Back Concerne le back-end Django label Jul 3, 2022
@Situphen Situphen linked a pull request Jul 4, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-Back Concerne le back-end Django
Projects
Status: À trier
Development

Successfully merging a pull request may close this issue.

1 participant