Signal public
Un participant au forum Google Developers a signalé une configuration Workspace vers BigQuery qui produisait zéro ligne. Les suggestions du forum sont des pistes utiles, pas une résolution universelle.
Comment PunchOp mènerait l’investigation
- Noter la date d’activation de l’export et la source Workspace choisie.
- Vérifier le projet, le dataset, la région, les permissions et la création réelle des tables.
- Examiner le schéma actuel du client au lieu de recopier une ancienne requête.
- Limiter la requête à un message test et une date connus.
- Estimer les octets analysés avant l’exécution et fixer une limite de facturation lorsque c’est applicable.
- Distinguer « aucun événement exporté », « mauvaise table » et « requête sans correspondance ».
Pourquoi cette distinction compte
Un résultat vide peut apparaître à plusieurs niveaux. Les résumer par « Google n’a rien exporté » masque la prochaine vérification utile et multiplie les essais de requêtes.
Limite importante
PunchOp n’a pas reproduit l’environnement du participant au forum. L’intérêt générique pour les coûts BigQuery dépasse également largement le problème d’investigation Workspace.
Ce que cette preuve permet et n’autorise pas de conclure
Les lignes BigQuery prouvent des événements Gmail exportés pour le schéma et la fenêtre interrogés—ni que Email Log Search correspondrait, ni que chaque échec relais est dans l’export. Zéro ligne prouve seulement que cette requête sur ces tables n’a rien renvoyé.
Si le message n’apparaît jamais chez Google
Un export vide n’explique pas un message manquant tant qu’on n’a pas séparé délai de mise en service, mauvais dataset, dérive de schéma et filtres de requête. L’incident peut rester visible dans Email Log Search même si BigQuery est vide—ou l’inverse.
Différence avec un outil ponctuel ou un rapport DMARC
BigQuery est une preuve Google à l’échelle ; DMARC et les outils d’en-têtes répondent à d’autres questions. Voir Reports API vs BigQuery et Sumo Logic.