Limites et considérations - AWS Glue

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Limites et considérations

Les restrictions du connecteur Google Analytics 4 sont les suivantes :

  • Pour l’entité Core Report, seuls neuf champs de dimension et dix champs de métriques sont autorisés à envoyer une demande. Si le nombre de champs autorisés est dépassé, la demande échouera et le connecteur enverra un message d’erreur.

  • Pour l’entité Real-Time Report, seuls les champs de quatre dimensions sont autorisés à envoyer une demande. Si le nombre de champs autorisés est dépassé, la demande échouera et le connecteur enverra un message d’erreur.

  • Google Analytics 4 est un outil gratuit en version bêta. Il y aura donc des mises à jour régulières sur les nouvelles fonctionnalités, l’amélioration des entités, l’ajout de nouveaux champs et le retrait des champs existants.

  • Les champs Core Report étant remplis de manière dynamique, des champs seront ajoutés, rendus obsolètes et renommés, et l’imposition de nouvelles limites aux champs peut avoir lieu à tout moment.

  • La date de début par défaut est de 30 jours et la date de fin est hier (un jour avant la date actuelle), et ces dates seront remplacées dans le code d’expression du filtre si l’utilisateur a défini la valeur OU si le flux est incrémentiel.

  • Selon la documentation, l’entité Real-Time Report renvoie 10 000 enregistrements si la limite n’est pas transmise dans la demande, sinon l’API renvoie un maximum de 250 000 lignes par demande, quel que soit le nombre que vous demandez. Pour plus d’informations, consultez Method: properties.runRealtimeReport dans la documentation de Google Analytics.

  • L’entité Real-Time Report ne prend pas en charge la partition basée sur les enregistrements, car elle ne prend pas en charge la pagination. De plus, elle ne prend pas en charge la partition basée sur les champs, car aucun des champs ne répond aux critères définis.

  • La raison est la restriction du nombre de champs qui peuvent être transmis dans une demande. Nous définissons les champs de dimension et de métrique par défaut dans les limites indiquées. Si « Tout sélectionner » est sélectionné, seules les données de ces champs prédéterminés seront extraites.

    • Core Report

      • Conformément aux restrictions de SAAS, les demandes sont autorisées pour un maximum de 9 dimensions et de 10 métriques uniquement (c’est-à-dire qu’une demande peut contenir un maximum de 19 champs [métriques + dimension]).

      • Conformément à l’implémentation : si l’utilisateur utilise SELECT_ALL ou sélectionne plus de 25 champs, les champs par défaut seront transmis dans la demande.

      • Les champs suivants sont considérés comme des champs par défaut pour Core Report : « country », « city », « eventName », « cityId », « browser », « date », « currencyCode », « deviceCategory », « transactionId », « active1DayUsers », « active28DayUsers », « active7DayUsers », « activeUsers », « averagePurchaseRevenue », « averageRevenuePerUser », « averageSessionDuration », « engagedSessions », « eventCount », « engagementRate ».

    • Real-Time Report

      • Conformément aux restrictions de SAAS, les demandes sont autorisées pour un maximum de quatre dimensions.

      • Si l’utilisateur transmet SELECT_ALL ou si les champs sélectionnés sont supérieurs à 15, les champs par défaut seront transmis dans la demande.

      • Les champs suivants sont considérés comme des champs par défaut pour Real-Time Report : « country », « deviceCategory », « city », « cityID », « activeUsers », « conversions », « eventCount », « screenPageviews ».

  • Dans l’entité Core-Report, si la partition sur le champ de date et le filtre sur StartDate sont présents simultanément. Dans ce cas, la valeur dateRange est remplacée par la valeur du filtre startDate, mais comme la partition doit toujours être la priorité, le filtre startDate est supprimé si la partition sur le champ de date est déjà présente.

  • Comme cohortSpecs fait désormais également partie du corps de la demande Core-Report, nous avons amélioré l’entité Core-Report actuelle pour inclure la prise en charge de l’attribut cohortSpec. Dans le corps de la demande cohortSpecs, presque tous les champs nécessitent une saisie par l’utilisateur. Pour résoudre ce problème, nous avons défini des valeurs par défaut pour ces attributs/champs et avons prévu des dispositions permettant à l’utilisateur de remplacer ces valeurs au besoin.

    FieldName Valeurs par défaut Exemple de requête pour transmettre les options filterPredicate afin de remplacer les valeurs par défaut
    startDate 30 jours à partir de la date actuelle "startDate between "2023-05-09" and "2023-05-10"
    endDate 1 jour à partir de la date actuelle "startDate between "2023-05-09" and "2023-05-10"
    startOffset 0 startOffset=2
    endOffset 1 endOffset=10
    granularité DAILY granularity="WEEKLY"

  • Vous pouvez également transmettre tous ces filtres ensemble en une seule fois ou avec d’autres filtres.

    • Exemple 1 : filterPredicate : startDate between "2023-05-09" and "2023-05-10" AND startOffset=1 AND endOffset=2 AND granularity="WEEKLY"

    • Example 2 : filterPredicate: city=“xyz” AND startOffset=1 AND endOffset=2 AND granularity="WEEKLY"

  • Dans le cadre d’une demande de cohorte :