Table des matières
Les API Google Adresses prend en charge la recherche de lieux, la saisie semi-automatique, la découverte des lieux à proximité, les informations sur les établissements et d’autres fonctionnalités liées à la localisation. Le véritable défi consiste à déterminer quel service « Places » convient le mieux à la tâche, quels champs il vaut la peine de demander et comment ces choix influent sur le coût.
L'évolution de Google vers l'API Places (nouvelle version) modifie la manière dont les développeurs gèrent les requêtes, la sélection des champs, les données de réponse et la facturation. Les anciens modèles de mise en œuvre ne sont pas toujours transposables tels quels, en particulier lorsque les masques de champs et la tarification basée sur les SKU entrent en jeu.
La configuration appropriée dépend de ce que vous développez. Une recherche de lieu au sein d’une application peut ne nécessiter qu’un ensemble restreint d’informations sur le lieu. Une équipe utilisant le API Google Places pour la génération de prospects Dans de nombreuses villes, un processus de travail différent peut s'avérer nécessaire. Traiter ces deux cas de figure de la même manière peut entraîner des coûts inutiles et un surcroît de travail au niveau des API.
Avant de choisir un point de terminaison ou d'estimer une utilisation mensuelle, il est utile de comprendre comment Google organise la recherche dans Google Places, la sélection des champs, la facturation et les quotas. Ces éléments permettent également de déterminer plus facilement dans quels cas l'API Places officielle est adaptée au projet et dans quels cas il est plus judicieux de recourir à un flux de travail distinct pour les données d'entreprise.
Réponse rapide : Comment fonctionne l'API Google Places ?
- Recherchez des lieux à l'aide de la recherche par texte ou de la recherche à proximité.
- Obtenez des informations détaillées, des photos et les identifiants de lieu (Place ID) pour des lieux spécifiques.
- Utilisez la fonction de saisie semi-automatique pour proposer des lieux au fur et à mesure que les utilisateurs tapent.
- Configurez un projet Google Cloud, la facturation et une clé API à accès restreint.
- Utilisez les masques de champ pour contrôler les données renvoyées et la facturation.
- Les coûts dépendent du service, des champs demandés et de l'utilisation.
- Pour les données d'entreprise en grande quantité ou les champs de contact supplémentaires, un autre processus de traitement des données pourrait s'avérer plus adapté.
Qu'est-ce que l'API Google Places ?
L'API Google Places fait partie de Google Maps Platform. Elle permet aux développeurs d'accéder par programmation aux informations relatives aux entreprises, aux points d'intérêt, aux adresses, aux emplacements géographiques et aux autres lieux répertoriés dans la base de données des lieux de Google.
Google indique actuellement que API « Places » (Nouveauté) fournit des données de localisation pour plus de 200 millions de lieux. Les développeurs peuvent s'en servir pour intégrer à leurs sites web, applications mobiles et autres logiciels des fonctionnalités de recherche de lieux, de découverte des environs, de saisie semi-automatique, de détails sur les lieux et de photos.
Une requête type commence par une requête de recherche, une zone géographique ou un identifiant de lieu connu. Google renvoie des informations structurées sur le lieu en fonction du type de requête et des champs sélectionnés par le développeur.
Par exemple, une application permettant de trouver des restaurants pourrait utiliser la « Recherche à proximité » pour identifier les restaurants situés à proximité de l'utilisateur. Une fois que l'utilisateur a sélectionné un restaurant, l'application pourrait demander les « Détails du lieu » afin d'obtenir des informations telles que son adresse, sa note, ses horaires d'ouverture, son numéro de téléphone ou les avis des clients.
Quelles données l'API Google Places peut-elle fournir ?
Les champs disponibles dépendent de la requête et des champs inclus dans le masque de champs. L'API Places (Nouvelle version) peut renvoyer des informations telles que :
| Type de données | Exemples de champs | Ce qu'il décrit |
|---|---|---|
| Identité | Nom du lieu, identifiant du lieu, type de lieu | Indique le lieu et sa catégorie. |
| Lieu | Adresse, coordonnées géographiques | Indique où se trouve cet endroit. |
| Informations sur l'entreprise | Statut de l'entreprise, numéro de téléphone, site web, horaires d'ouverture | Fournit des informations pratiques et les coordonnées. |
| Informations client | Notes, avis, informations sur les prix | Fournit des données relatives aux notes, aux avis et aux prix. |
| Médias | Photos | Renvoie les images disponibles associées à ce lieu. |
| Accessibilité | Informations sur l'accessibilité | Décrit les fonctionnalités d'accessibilité prises en charge. |
| Options de service | Livraison, repas sur place, retrait en bordure de trottoir | Affiche les options de service disponibles, le cas échéant. |
Google regroupe ces champs en différentes catégories tarifaires. Certains champs de base relèvent de références moins coûteuses, tandis que des champs tels que les notes, les horaires d'ouverture et les avis peuvent donner lieu à des références plus onéreuses. Google explique le lien entre les champs et la facturation dans son Documentation sur les champs de données de l'API Places. Ne demandez que les champs dont l'application a besoin, car la sélection des champs peut modifier la référence de facturation.
L'API Places (Nouvelle version) exige également un masque de champ pour les requêtes « Détails du lieu », « Recherche textuelle » et « Recherche à proximité ». Au moins un champ doit être spécifié. Une requête sans masque de champ renvoie une erreur.
Le rôle de l'API Places au sein de Google Maps Platform
L'API « Places » gère les informations relatives aux lieux, mais elle ne constitue qu'une partie de la plateforme Google Maps.
Un développeur peut utiliser l'API Places pour rechercher une entreprise, puis recourir à un autre service de Google Maps Platform pour une tâche différente. Par exemple, l'API de géocodage permet de convertir une adresse en coordonnées, tandis que les services d'itinéraire permettent de calculer des itinéraires ou des temps de trajet entre deux lieux.
Au sein même de l'API Places, les principaux services gèrent différentes étapes du processus de recherche de lieux :
- Recherche de texte recherche des lieux à partir de requêtes écrites.
- Recherche à proximité permet de localiser des lieux au sein d'une zone géographique définie.
- Détails du lieu récupère des informations sur un lieu connu.
- Saisie semi-automatique propose des lieux au fur et à mesure que l'utilisateur tape.
- Photos de lieux récupère les images disponibles associées à un lieu.
Google recommande d'utiliser Détails du lieu lorsque l'identifiant du lieu est déjà connu, car il n'est pas nécessaire d'effectuer une nouvelle requête de recherche pour ce même lieu.
Une recherche d'entreprise dans une ville, un champ de saisie semi-automatique et une demande d'informations sur un lieu connu nécessitent chacun une méthode différente de l'API Places.
Fonctionnement de l'API Google Places
L'API Google Places utilise différentes méthodes en fonction des données dont vous disposez déjà et du type de données relatives aux lieux dont vous avez besoin.
Une requête écrite, un ensemble de coordonnées et un identifiant de lieu connu nécessitent chacun une méthode différente. L'API Places (nouvelle version) propose actuellement la recherche textuelle, la recherche à proximité, les détails du lieu, la saisie semi-automatique et les photos du lieu pour ces tâches.
Recherche de texte
La recherche textuelle permet de trouver des lieux à partir d'une requête écrite, telle qu'un nom d'entreprise, une catégorie, une adresse ou une expression comme pizza in New York.
La recherche textuelle (nouvelle fonctionnalité) utilise une requête HTTP POST et renvoie les objets « Lieu » correspondant. Des paramètres facultatifs permettent d'affiner les résultats en fonction de l'emplacement, du type de lieu, des horaires d'ouverture, de la note ou de la gamme de prix.
Google affiche actuellement jusqu'à 60 résultats sur l'ensemble des pages et précise que des requêtes identiques ne donnent pas toujours lieu à la même liste de résultats.
Recherche à proximité
La recherche à proximité permet de trouver des lieux situés dans une zone géographique définie.
La requête utilise la latitude, la longitude et le rayon, puis filtre les résultats en fonction d'un ou plusieurs types de lieux. Par exemple, une application pourrait rechercher des restaurants situés à une distance donnée d'un hôtel.
La recherche à proximité (Nouveauté) utilise également la méthode HTTP POST et nécessite un masque de champ pour les données renvoyées.
Détails du lieu
La fonction « Détails du lieu » permet d'obtenir des informations sur un lieu connu à l'aide de son identifiant de lieu.
Voici un exemple de déroulement courant :
- Trouvez un lieu grâce à la recherche par texte, à la recherche à proximité ou à la saisie semi-automatique.
- Conserver son identifiant de lieu.
- Ne demandez que les informations dont l'application a besoin.
Cela évite de lancer une nouvelle recherche lorsque le lieu a déjà été identifié.
Saisie semi-automatique
La fonction de saisie semi-automatique propose des lieux au fur et à mesure que l'utilisateur tape dans le champ de recherche.
Un jeton de session permet de regrouper les requêtes de l'utilisateur au sein d'une seule session de recherche à des fins de facturation. Chaque nouvelle recherche doit utiliser un nouveau jeton, et la session doit se terminer par une requête « Détails du lieu » ou « Validation d'adresse » compatible.
Lieux et identifiants de lieux
La fonction « Photos d'un lieu » récupère les images associées à un lieu lorsque le photos Ce champ est renvoyé par la recherche textuelle, la recherche à proximité ou les détails du lieu.
Les identifiants de lieu permettent d'identifier des lieux spécifiques afin de pouvoir y faire référence à nouveau dans l'ensemble des services pris en charge par Google Maps Platform.
Par exemple, une application peut trouver un établissement grâce à la recherche textuelle, enregistrer son identifiant de lieu, puis demander les détails de ce lieu sans avoir à répéter la recherche initiale.
API Places (nouvelle version) vs API Places (ancienne version)
Google a classé l'API Places d'origine comme « obsolète » le 1er mars 2025. Les projets existants peuvent toujours l'utiliser, mais les nouveaux projets Cloud ne peuvent pas activer les services obsolètes.
L'API Places (Nouvelle version) est désormais la version recommandée par Google pour les nouveaux développements. Les modifications concernent les méthodes de requête, la sélection des champs, la structure des réponses, l'authentification et la facturation.
Quelles sont les nouveautés de l'API Places (nouvelle version) ?
La recherche textuelle et la recherche à proximité utilisent désormais la méthode HTTP POST au lieu du modèle basé sur GET utilisé par la version précédente.
L'API « Places » (nouvelle) prend également en charge les clés API et OAuth, renvoie des réponses au format JSON et nécessite des masques de champ pour les détails des lieux, la recherche textuelle et la recherche à proximité.
« Find Place » n'a pas de nouvelle version correspondante. Google redirige ces recherches vers « Text Search ».
Masques de champ et modifications des réponses
Les masques de champ constituent l'une des principales différences entre l'API Places (nouvelle version) et l'ancienne API.
Pour les fonctions « Détails du lieu », « Recherche textuelle » et « Recherche à proximité », la requête doit spécifier au moins un champ à renvoyer. Si le masque de champ n'est pas fourni, la requête échouera.
Le choix des champs a également une incidence sur la facturation, car Google attribue des champs de données géographiques à différentes références produit. La section consacrée aux tarifs, plus loin dans cet article, explique cette relation plus en détail.
Les objets de réponse ont également évolué. L'API Places (nouvelle version) utilise des noms de champs en « camelCase » à la place de nombreux noms en « snake_case » présents dans les réponses de l'ancienne version.
En voici quelques exemples :
adresse_formatéedevientadresse formatéebusiness_statusdevientstatut de l'entreprisenuméro_de_téléphone_formatédevientnuméro de téléphone nationalgéométrie.emplacementdevientlocalisation
La recherche par texte et la recherche à proximité affichent également les résultats dans un lieux « array » plutôt que « Legacy » résultats tableau. Les informations d'état et d'erreur utilisent désormais les codes de réponse HTTP standard et les messages correspondants, au lieu des champs hérités tels que statut et l' message d'erreur.
Ces modifications sont importantes lorsque des applications existantes analysent des réponses « Legacy » ou s'appuient sur d'anciens noms de champs.
Ce que les utilisateurs de l'API héritée doivent savoir au sujet de la migration
La migration nécessite généralement plus qu'un simple changement de point de terminaison. Google propose une Guide de migration de l'API « Places » présentant les principales différences entre l'API Legacy et l'API Places (nouvelle version).
Vérifiez d'abord ces points :
- Déplacer les recherches « Trouver un lieu » vers la « Recherche textuelle » (Nouveau).
- Remplacer les requêtes « Recherche de texte » et « Recherche à proximité » de GET par POST.
- Ajoutez les masques de champ obligatoires.
- Mettre à jour le code qui lit les champs de réponse « Legacy ».
- Vérifiez la référence (SKU) utilisée pour chaque demande.
Vérifiez également que l'API Places (Nouvelle version) est activée dans le projet et autorisée par les restrictions de la clé API.
Si les requêtes « Legacy » et « New » doivent s'exécuter simultanément pendant les tests, veillez à séparer les deux flux. Google recommande d'utiliser des clés API distinctes pendant la migration.
Les intégrations existantes (héritées) peuvent continuer à fonctionner pour l'instant, mais les nouveaux projets doivent utiliser l'API Places (nouvelle version).
Tutoriel sur l'API Google Places : configuration et première requête
Pour utiliser l'API Places (nouvelle version), vous devez disposer d'un projet Google Cloud associé à un compte de facturation. L'API Places (nouvelle version) doit être activée pour ce projet avant que des requêtes authentifiées puissent être envoyées.
Pour une requête de service web simple, la procédure de configuration se déroule en cinq étapes : choisir un projet Cloud, activer l'API, créer une clé API, restreindre l'accès à cette clé, puis envoyer une requête en indiquant les champs dont vous souhaitez obtenir les résultats.
Créer ou sélectionner un projet Google Cloud
Chaque requête Google Maps Platform appartient à un projet Google Cloud.
Vous pouvez créer un nouveau projet ou utiliser un projet existant. Le projet sélectionné doit également être associé à un compte de facturation actif. Google utilise ce projet pour suivre l'accès à l'API, son utilisation, les quotas et les frais.
Il peut également être judicieux de séparer les projets lorsque les environnements de développement, de test et de production nécessitent des identifiants ou des contrôles d'accès différents.
Une fois le projet approprié sélectionné, l'API Places (nouvelle version) peut être activée depuis la console Google Cloud.
Activer l'API Places (Nouveau)
L'API Places (Nouvelle) doit être activée pour le projet avant que l'application puisse appeler ses méthodes de service Web.
Dans la console Google Cloud :
- Sélectionnez le projet que vous souhaitez utiliser.
- Ouvrez la API et services.
- Rechercher API « Places » (Nouveauté) dans la bibliothèque d'API.
- Activez-le pour le projet.
Cette distinction est importante pour les anciens projets, car l'API Places (ancienne version) et l'API Places (nouvelle version) sont deux services distincts. Un projet qui utilisait auparavant l'API ancienne version peut encore nécessiter l'activation de l'API Places (nouvelle version) pour que les nouveaux points de terminaison fonctionnent.
Configuration et restrictions relatives aux clés API
Une clé API identifie le projet Google Cloud à l'origine de la requête.
Google exige que la facturation soit activée avant de pouvoir utiliser l'API Places (Nouvelle version) pour des requêtes en production. Si vous suivez simplement la procédure de configuration et que vous ne souhaitez pas encore associer de compte de facturation, vous pouvez vous arrêter avant de créer la clé et revenir à cette étape ultérieurement.
Lorsque la facturation est activée, créez une clé API dans la console Google Cloud et limitez son accès avant de l'utiliser dans une application.
Pour les requêtes côté serveur adressées à l'API Places, une restriction d'adresse IP permet de limiter l'utilisation de la clé aux serveurs autorisés. Vous pouvez également restreindre la clé afin qu'elle ne fonctionne qu'avec l'API Places (Nouvelle version) et les autres services de Google Maps Platform dont l'application a réellement besoin.
Google exige également que les requêtes adressées au service Web Places API utilisent le protocole HTTPS. L'absence d'une clé, une restriction incorrecte ou une configuration non prise en charge peut entraîner un REQUEST_DENIED réponse.
Exemples d'utilisation de l'API Google Places : effectuer votre première requête de recherche textuelle
« Recherche de texte » est un exemple simple utilisant l'API Google Places qui permet de comprendre le format de la requête, l'en-tête de clé API et le masque de champ.
L'API « Places » (nouvelle) envoie des requêtes de recherche textuelle à :
https://places.googleapis.com/v1/places:searchText
La requête utilise la méthode HTTP POST. Le texte à rechercher est inclus dans le corps JSON, tandis que la clé API et le masque de champ peuvent être envoyés via les en-têtes de la requête.
Une requête simple peut se présenter comme suit :
curl -X POST \
-H "Content-Type: application/json" \
-H "X-Goog-Api-Key: YOUR_API_KEY" \
-H "X-Goog-FieldMask: places.id,places.displayName,places.formattedAddress" \
-d '{ "textQuery": "dentists in Chicago" }' \
"https://places.googleapis.com/v1/places:searchText"
Cette requête recherche dentists in Chicago et demande à Google de ne renvoyer que :
- ID du lieu
- nom d'affichage
- adresse mise en forme
Une réponse réussie renvoie les objets « Place » correspondants à l'intérieur d'un places tableau. Les champs inclus dans chaque résultat dépendent du masque de champs utilisé dans la requête.
L'utilisation d'un masque à champs limités facilite la lecture des résultats et évite de demander des données dont l'application n'a pas besoin.
Pour connaître les paramètres de requête actuels, les champs pris en charge, les quotas et les modifications apportées à l'API, consultez le site officiel Documentation de l'API Google Places.
Exemple d'utilisation de l'API Google Places : récupération des informations sur un lieu
Une réponse à une requête de recherche textuelle peut renvoyer un identifiant de lieu (Place ID) pour chaque lieu correspondant. Une fois que l'application dispose de cet identifiant, elle peut utiliser les détails du lieu (Place Details) pour demander des informations sur ce lieu spécifique sans avoir à lancer une nouvelle recherche.
La requête suit ce modèle :
https://places.googleapis.com/v1/places/PLACE_ID
Par exemple :
curl -X GET -H "Content-Type: application/json" -H "X-Goog-Api-Key: YOUR_API_KEY" -H "X-Goog-FieldMask: id,displayName,formattedAddress" "https://places.googleapis.com/v1/places/PLACE_ID"
Remplacer PLACE_ID avec l'identifiant renvoyé par la recherche textuelle, la recherche à proximité ou une autre méthode « Places » prise en charge.
Notez que le masque du champ « Détails du lieu » utilise id, displayNameet formattedAddress plutôt que places.id, places.displayNameet places.formattedAddress. La méthode « Place Details » renvoie un objet « Place », tandis que la méthode « Text Search » renvoie des objets « Place » contenus dans un places tableau.
Sélectionnez les champs dont vous avez besoin
Les fonctionnalités « Détails du lieu », « Recherche textuelle » et « Recherche à proximité » nécessitent un masque de champ dans l'API Places (Nouvelle version). Si aucun champ n'est spécifié, la requête renvoie une erreur.
Pour la recherche textuelle, un masque de champ pourrait se présenter comme suit :
places.displayName,places.formattedAddress
Si l'application nécessite également un site web et une notation, le masque de champ peut être étendu :
places.displayName,places.formattedAddress,places.websiteUri,places.rating
Google prend également en charge * comme caractère générique pour tous les champs disponibles, mais son utilisation est déconseillée en production. La demande de champs superflus peut augmenter le volume de données renvoyées et faire passer la requête dans une catégorie tarifaire supérieure.
Limitez le masque de champ aux données réellement utilisées par l'application. La sélection des champs a une incidence à la fois sur la réponse et sur le coût de la requête.
La section ci-dessous consacrée à la tarification explique comment ces choix de champs correspondent aux SKU de l'API Google Places.
Utilisez Outscraper Le Scraping Google Maps pour collecter des données d'entreprise via un workflow « no-code » sans avoir à configurer de requêtes individuelles auprès de l'API Places.
Tarifs et utilisation gratuite de l'API Google Places
L'API Google Places fonctionne selon un modèle de tarification à l'utilisation. Chaque requête est facturée sous une référence produit (SKU) spécifique, et son coût dépend de la méthode utilisée, des champs demandés et du nombre d'événements facturables par mois.
Google n'utilise plus l'ancien crédit récurrent « $200 » de la plateforme Maps. Le modèle actuel attribue à chaque SKU son propre plafond d'utilisation gratuite mensuel. Ces plafonds sont réinitialisés au début de chaque mois.
Fonctionnement des SKU de l'API Google Places
Un SKU est la catégorie de facturation associée à une requête de l'API Places.
L'API Places (Nouvelle version) classe de nombreuses requêtes en différents niveaux tarifaires, tels que « Essentials », « Pro » et « Enterprise ». Les champs demandés peuvent faire passer une requête dans une référence (SKU) plus onéreuse.
Par exemple, les « Détails du lieu » peuvent être facturés sous différentes références (SKU) en fonction des champs demandés :
- Informations essentielles sur le lieu comprend un plafond mensuel d'utilisation gratuite de 10 000 événements.
- Le plafond mensuel d'utilisation gratuite pour Détails du lieu Pro soit 5 000 événements.
- Pour Détails du lieu : Entreprise, le plafond mensuel d'utilisation gratuite est de 1 000 événements.
Une fois la limite d'utilisation gratuite atteinte, la tarification s'applique par tranche de 1 000 événements et diminue à mesure que le volume mensuel augmente.
La recherche par texte et la recherche à proximité suivent une structure similaire.
Pour le premier niveau d'utilisation payant, Google indique actuellement les tarifs suivants sur le site officiel Page des tarifs de Google Maps Platform:
*Ces chiffres correspondent au premier niveau tarifaire indiqué sur la page mondiale des tarifs de Google. Les volumes mensuels plus élevés bénéficient de tarifs par 1 000 moins élevés.
Google propose également certaines références (SKU) réservées aux identifiants (ID), avec une utilisation gratuite et illimitée, notamment « Place Details Essentials (ID uniquement) » et « Text Search Essentials (ID uniquement) ».
Limites d'utilisation gratuite actuelles
L'utilisation gratuite est associée à chaque référence (SKU) individuellement, et non à un crédit commun en dollars.
Par exemple :
- Demandes de saisie semi-automatique : 10 000 événements gratuits par mois
- Informations essentielles sur le lieu : 10 000
- Détails du lieu Pro : 5 000
- Text Search Pro : 5 000
- Nearby Search Pro : 5 000
- Détails du lieu Entreprise : 1 000
- Recherche textuelle en entreprise : 1 000
- Recherche d'entreprises à proximité : 1 000
Certains services accessibles uniquement avec un identifiant offrent une utilisation gratuite et illimitée.
Les estimations de coûts dépendent donc davantage de la requête précise que dans l'ancien système de crédits. Deux applications effectuant le même nombre d'appels à l'API Places peuvent générer des factures différentes si elles demandent des champs différents ou utilisent des méthodes différentes.
Comment les champs obligatoires influent sur la facturation
Les masques de champ ne déterminent pas uniquement la taille de la réponse.
Pour les fonctionnalités « Détails du lieu », « Recherche textuelle » et « Recherche à proximité », Google facture la requête en fonction de la référence (SKU) la plus élevée correspondant aux champs demandés. Si le masque de champs comprend à la fois des champs de la version Essentials et de la version Pro, la requête est facturée au tarif de la version Pro.
Par exemple, une application qui n'a besoin que d'un identifiant de lieu et d'une adresse n'aura peut-être pas besoin des mêmes champs qu'une autre qui demande des notes, des horaires d'ouverture, des avis et d'autres caractéristiques relatives au lieu.
La sélection des champs fait ainsi partie intégrante du calcul des coûts.
Évitez de demander par défaut tous les champs disponibles. Commencez par les champs requis par la fonctionnalité et n'ajoutez les autres que s'ils ont une utilité claire.
Comment les sessions de saisie semi-automatique influent sur la facturation
La fonction de saisie semi-automatique peut être facturée à la requête ou dans le cadre d'une session.
En l'absence de jeton de session, chaque requête de saisie semi-automatique est facturée séparément au titre de la référence « Requêtes de saisie semi-automatique ».
Une session regroupe les requêtes de saisie semi-automatique d'un utilisateur avec la requête qui finalise la sélection. Une session type commence par un ou plusieurs appels de saisie semi-automatique et se termine par la page « Détails du lieu (Nouveau) » ou par la validation d'adresse. Chaque nouvelle recherche effectuée par un utilisateur doit utiliser un nouveau jeton de session.
Pour les sessions qui se terminent par une requête « Place Details Essentials », Google facture actuellement les 12 premières requêtes de saisie semi-automatique individuellement. Les requêtes au-delà de la 12e sont facturées dans le cadre de l’utilisation de la session de saisie semi-automatique, qui est gratuite. La requête « Place Details » de fin de session reste facturée sous sa propre référence produit (SKU).
Les sessions abandonnées ne bénéficient pas de ce traitement. Si l'utilisateur ne termine jamais sa session par la page « Détails du lieu » ou la « Validation de l'adresse », les appels à la fonctionnalité de saisie semi-automatique reviennent à la tarification à la requête.
Comment estimer les coûts liés à l'API Google Places
Pour établir une estimation de coût pertinente, il faut partir du flux réel de requêtes plutôt que du nombre total d'utilisateurs.
Vérifier :
- Quelle méthode de l'API Places sera appelée ?.
- Nombre de fois où la méthode est appelée au cours d'une action de l'utilisateur.
- Quels sont les champs inclus dans le masque de champ ?.
- À quelle référence ces champs correspondent-ils ?.
- Combien d'événements facturables sont prévus chaque mois ?.
- Quelle part de cette utilisation est comprise dans le plafond mensuel gratuit de la SKU ?.
- Les requêtes de saisie semi-automatique sont-elles regroupées en sessions correctement menées à terme ?.
Par exemple, une application effectuant 20 000 requêtes « Place Details Essentials » par mois utiliserait d'abord le quota mensuel gratuit de 10 000 événements. Les 10 000 événements restants relèveraient du niveau tarifaire payant.
Au tarif actuel de premier niveau, fixé à $5 pour 1 000 événements, ces 10 000 requêtes payantes coûteraient environ $50, hors taxes et hors autres frais d'utilisation de Maps Platform.
Le calcul change si le masque de champ déclenche une référence « Pro » ou « Enterprise » ; les champs attendus doivent donc être pris en compte dès le début dans l'estimation des coûts.
Quand l'API Google Places est-elle l'outil adapté, et quand ne l'est-elle pas ?
L'API Google Places fonctionne bien lorsque les informations sur les lieux font partie intégrante d'une fonctionnalité de l'application. Un champ de recherche, un localisateur de magasins, une application de voyage, une interface de livraison ou une fonctionnalité permettant de trouver des commerces à proximité peuvent demander des informations sur les lieux lorsque l'utilisateur en a besoin.
Les exigences changent lorsque l'objectif principal est de constituer un ensemble de données métier. La collecte d'enregistrements couvrant de nombreuses catégories, villes ou régions ne suit pas le même processus que la recherche de lieux au sein d'une application.
Pour une comparaison plus approfondie entre l'accès aux API officielles et l'extraction de données à grande échelle, voir API Google Maps vs. extraction de données sur le Web.
Quand l'API Google Places fonctionne correctement
Google a conçu l'API Places (Nouvelle version) autour des fonctionnalités des applications géolocalisées.
C'est une solution particulièrement adaptée lorsqu'une application doit :
- rechercher des lieux à partir des informations fournies par l'utilisateur
- trouver des commerces ou des lieux d'intérêt à proximité
- proposer des suggestions au fur et à mesure que l'utilisateur tape
- obtenir des informations sur un lieu connu
- afficher des photos du lieu
- Utiliser les identifiants de lieu dans l'ensemble des services pris en charge de la plateforme Google Maps
Par exemple, une application de réservation d'hôtels pourrait afficher les restaurants situés à proximité d'un établissement sélectionné. Une application de livraison pourrait utiliser la fonction de saisie semi-automatique pour aider un client à saisir une destination. Un localisateur de magasins pourrait récupérer des informations sur une succursale spécifique une fois que l'utilisateur l'a sélectionnée.
Ces requêtes s'inscrivent généralement dans le cadre d'une interaction au sein de l'application. C'est le développeur qui détermine quelle méthode est appelée, quels champs sont renvoyés et comment les résultats s'affichent pour l'utilisateur.
La documentation de Google décrit l'API Places (Nouvelle version) en mettant l'accent sur ces types de fonctionnalités : recherche de lieux, consultation, saisie semi-automatique et applications géolocalisées.
Lorsque vous avez besoin de données professionnelles en grande quantité
Certains projets nécessitent un ensemble de données plutôt qu'une fonctionnalité de recherche par lieu.
Au lieu de demander :
Quels sont les restaurants situés à proximité de cet utilisateur ?
Une équipe de recherche peut avoir besoin :
Quels sont les restaurants présents dans ces 50 villes ?
On observe la même tendance dans différentes équipes :
- Développeurs Il peut être nécessaire d'effectuer une recherche par lieu ou de consulter des informations spécifiques au sein d'une application.
- Professionnels du marketing pourra peut-être avoir besoin d'une liste d'entreprises classées par catégorie et par lieu dans le cadre d'une étude de marché.
- Équipes commerciales peut avoir besoin de données commerciales répondant à des critères géographiques ou liés à l'entreprise.
- Spécialistes des données peuvent avoir besoin de données structurées à des fins d'analyse, de tableaux de bord ou de systèmes internes.
Lorsque le travail consiste à collecter des centaines, voire des milliers de documents commerciaux, le processus passe de la recherche ponctuelle à la collecte de données.
Pour les études de marché, voir Quelles données professionnelles de Google Maps faut-il collecter pour une analyse de marché ? avant de déterminer quels champs doivent figurer dans votre ensemble de données.
Une solution « sans code » pour la collecte de données d'entreprise
Les équipes qui n'ont pas besoin de développer une fonctionnalité de recherche de lieux peuvent utiliser Outscraper Le Scraping Google Maps pour collecter des données d'entreprise sans avoir à configurer de requêtes Google Cloud ni à écrire de code API.
Les utilisateurs peuvent effectuer des recherches par catégorie et par lieu, lancer la collecte via l'interface Web et exporter les résultats à des fins de recherche, de prospection ou d'analyse.
Pour les développeurs et les équipes chargées des données qui ont besoin d'un accès programmatique, Outscraper API Places de Google Maps est un service distinct de celui de Google API « Places » (Nouveauté). Il prend en charge la collecte en masse de données d'entreprise. Voir la Documentation de l'API Outscraper pour plus de détails sur la demande.
Une application nécessitant une recherche de lieux à proximité n'a pas les mêmes besoins en matière de données qu'une équipe chargée de constituer un ensemble de données métier réutilisable.
Utilisez Outscraper API Places de Google Maps lorsque vous avez besoin de documents d'entreprise relevant de plusieurs catégories ou provenant de plusieurs sites à des fins de recherche, de vente, d'analyse ou dans le cadre d'un autre processus de traitement des données.
Lorsque vous avez besoin d'informations supplémentaires sur une entreprise ou d'une adresse de contact
L'API Google Places peut fournir des adresses, des numéros de téléphone, des sites Web, des notes, des avis, des horaires d'ouverture, le statut de l'établissement et d'autres informations relatives au lieu.
Dans le cadre de la prospection ou d'études de marché, cela peut toutefois laisser des lacunes. Les équipes peuvent également avoir besoin d'adresses e-mail, de coordonnées, de profils sur les réseaux sociaux ou d'autres informations sur l'entreprise avant qu'une fiche ne soit prête à l'emploi.
Si vous devez ajouter des coordonnées et des informations sur l'entreprise après avoir collecté des données sur un lieu, consultez le guide intitulé Enrichissement des données de Google Maps Places.
Voici un exemple de déroulement typique :
- Recherchez des entreprises par catégorie et par lieu.
- Conservez les champs nécessaires au ciblage.
- Ajouter les coordonnées d'un contact ou d'une entreprise.
- Exportez les enregistrements vers un système de vente, de recherche ou tout autre système.
Outscraper prend en charge la collecte de données d'entreprise via des workflows « sans code » et par API, avec des options d'enrichissement supplémentaires pour les e-mails, les contacts et les profils sur les réseaux sociaux.
L'API Google Places permet d'intégrer la recherche de lieux et les informations détaillées sur ces derniers dans des applications. Les flux de travail liés aux données d'entreprise qui nécessitent des coordonnées, un enrichissement ou une exportation requièrent généralement des outils supplémentaires.
Limites, quotas et risques liés à la facturation de l'API Google Places
Une configuration de l'API Places peut fonctionner en environnement de test, mais peut néanmoins rencontrer des problèmes liés aux coûts, aux quotas ou à l'accès dès que l'utilisation augmente.
Google applique des quotas par méthode API et par projet, plutôt que par le biais d'une limite quotidienne commune. L'utilisation, les quotas, les erreurs et la facturation peuvent être consultés dans la Google Cloud Console.
Ne demandez que les champs dont vous avez besoin
Les masques de champ ont une incidence à la fois sur la réponse et sur la référence de facturation.
Si une requête comprend des champs de niveau « Pro », Google peut facturer cette requête au tarif « Pro », même si elle contient également des champs moins coûteux. Veillez à limiter le masque de champ aux données réellement utilisées par l'application.
Utilisez la bonne méthode de recherche
La recherche textuelle s'effectue à partir d'une requête écrite. La recherche à proximité s'effectue à partir d'une zone géographique définie et de critères relatifs au type de lieu.
Par exemple :
cafés à Bostonconvient à la recherche textuelle.- les restaurants situés dans un rayon donné correspondent à la recherche « À proximité ».
Le choix d'une méthode adaptée permet de réduire les requêtes superflues et les filtrages supplémentaires.
Gérer correctement les sessions de saisie semi-automatique
La fonction de saisie semi-automatique peut générer plusieurs requêtes pendant que l'utilisateur tape son texte.
Utilisez un nouveau jeton de session pour chaque session de recherche et terminez la session par une requête « Détails du lieu » ou « Validation d'adresse » compatible. Les sessions abandonnées ou mal configurées peuvent être facturées comme des requêtes distinctes.
Séparer les demandes existantes des nouvelles demandes
L'API Places (ancienne version) et l'API Places (nouvelle version) utilisent des formats de requête, des noms de champs et des structures de réponse différents.
Ne mélangez pas les jetons de session de saisie semi-automatique entre les requêtes « Legacy » et « New ». Vérifiez les anciennes intégrations avant de basculer le trafic de production vers l'API Places (New).
Limitez l'utilisation de vos clés API
Google recommande de limiter l'utilisation des clés API par application et par API.
Pour les requêtes côté serveur, les restrictions d'adresse IP peuvent limiter les endroits où la clé peut être utilisée. Les restrictions liées à l'API peuvent limiter l'utilisation de cette même clé à l'API Places (Nouvelle) et à d'autres services requis.
Une clé mal configurée peut également entraîner DEMANDE_REFUSÉE des erreurs ; il convient donc de tester ces restrictions avant leur mise en production.
Définir des quotas et des alertes de facturation
La console Google Cloud permet de suivre le trafic, les erreurs, les quotas et les dépenses.
Définissez des limites de quota et des alertes de facturation avant que le volume de requêtes n'augmente. Les alertes de facturation vous avertissent lorsque les dépenses atteignent les seuils définis, mais elles n'interrompent pas automatiquement l'utilisation de l'API.
Liste de contrôle finale : avant d'utiliser l'API Google Places
- Choisissez la méthode de l'API Places qui correspond à la tâche.
- Utilisez l'API Places (nouvelle version) et ne demandez que les champs dont vous avez besoin.
- Vérifiez la référence (SKU), le plafond d'utilisation gratuite et le coût mensuel estimé.
- Limitez l'utilisation de la clé API et définissez des quotas ou des alertes de facturation.
- Déterminez si vous avez besoin d'une fonctionnalité de recherche de lieux via une application ou d'une collecte de données professionnelles en masse.
Utilisation Outscraper Google Maps Places API pour collecter des données commerciales sur plusieurs sites ou dans plusieurs catégories.
FAQ
Questions et réponses les plus fréquentes
L'API Google Places n'est pas entièrement gratuite. Google propose une tarification à l'utilisation avec des plafonds d'utilisation mensuels gratuits pour chaque référence (SKU). Par exemple, les requêtes de saisie semi-automatique et les informations de base sur les lieux (Place Details Essentials) comprennent actuellement 10 000 événements gratuits par mois, tandis que d'autres références ont des plafonds inférieurs.
L'API Places sert à rechercher des lieux et à obtenir des informations sur des commerces, des sites touristiques et d'autres lieux. L'API Geocoding est principalement utilisée pour convertir des adresses en coordonnées ou, inversement, des coordonnées en adresses. Les deux API peuvent fonctionner avec des identifiants de lieu (Place ID), mais elles répondent à des besoins différents en matière de données de localisation.
L'API Places fournit des données sur les lieux via des requêtes HTTP. L'API Maps JavaScript permet d'ajouter des cartes interactives et des fonctionnalités cartographiques dans un navigateur à des sites web. Sa bibliothèque « Places » permet également d'intégrer une fonctionnalité de recherche de lieux et de saisie semi-automatique au sein d'une application web.
Oui. Un projet de production utilisant l'API Places doit être associé à un projet Google Cloud lié à un compte de facturation. Le projet doit également disposer du service API Places requis, activé, ainsi que d'identifiants d'authentification valides.
Un « Place ID » est un identifiant textuel attribué à un lieu dans la base de données Google Places et sur Google Maps. Il peut être utilisé dans plusieurs services de la plateforme Google Maps, notamment l'API Places, l'API de géocodage, l'API JavaScript de Maps et l'API Routes. Google précise que les « Place ID » peuvent évoluer au fil du temps et recommande d'actualiser les identifiants enregistrés datant de plus de 12 mois.
L'API « Places » (Nouvelle version) est la version actuelle destinée aux nouveaux développements. Certaines méthodes de l'ancienne version correspondent directement aux nouvelles méthodes, tandis que d'autres ont été modifiées. Par exemple, la méthode « Text Search » (Nouvelle version) remplace la méthode « Find Place » (Ancienne version). Les projets existants utilisant l'ancienne version sont toujours pris en charge, mais les nouveaux projets Cloud ne peuvent plus activer les services de l'ancienne version.
Aucun champ « e-mail professionnel » n'apparaît dans la liste actuelle des champs de données de lieux (Nouveau) de l'API Places de Google. L'API peut renvoyer des champs tels que les numéros de téléphone et les URL de sites Web, mais les adresses e-mail professionnelles ne figurent pas parmi les champs de lieu pris en charge.
