透過 Places Insights 找出新的現場銷售待開發客戶

傳統的企業對企業待開發客戶開發方式，通常是購買靜態目錄或產業名單，藉此定義地域潛力。不過，這些靜態興趣點 (POI) 資料集幾乎立即就會過時。因為這些資料通常缺少最新的營業狀態或精細的場所類型分類，外勤銷售團隊可能會浪費寶貴時間，追蹤永久歇業、分類錯誤或與理想客戶設定檔無關的商家。

本指南提供工作流程，說明如何使用 Places Insights 和 Places API 縮小差距。將目前的業務範圍對應至地點 ID，即可使用 BigQuery 找出客戶關係管理 (CRM) 資料庫中尚未列出的區域內所有營運業務。本指南說明如何建構排除引擎，為外勤代表提供經過驗證的超精確目標客層待開發客戶清單。

這張圖表顯示如何使用 Places API 和 BigQuery Places Insights 處理現有的 CRM 資料，產生經過驗證的全新待開發客戶。

應用程式範例

假設某銷售點 (POS) 供應商打算在紐約市擴展現場銷售業務。一般來說，機構會依郵遞區號提取食品和飲料場所總數的報表。這種做法可能會導致業務代表依賴過時的資料，例如永久歇業的地點，或是不相關的待開發客戶，例如沒有店面的私人餐飲廚房。不妨改用 Places Insights，這項現代化方法運用 Google 地圖的全球規模，以及從多個來源驗證的最新資料。Places Insights 支援近 500 個地點類別和超過 70 個屬性，可讓您根據特定商家類型 (例如 scandinavian_restaurant)、營業時間和服務項目 (例如 accepts_credit_cards) 精準鎖定潛在客戶。將 Places Insights 與內部 CRM 交叉參照，即可為銷售團隊提供高潛力且尚未聯絡的潛在客戶名單，協助他們精準鎖定目標。

解決方案工作流程

本指南提供技術框架，協助您建立動態「待開發客戶地圖」，自動篩除目前的業務書籍，只留下淨新、可運作的待開發客戶，供銷售團隊追蹤。

四步驟架構

定義目標地點類型：將理想顧客設定檔對應至地點類型。
找出高潛力區域：在 BigQuery 中執行地點計數函式，產生營運目標商家密度熱度圖。
將客戶關係管理資料正規化為地點 ID：透過資料清理管道處理非結構化客戶關係管理記錄，並運用地址驗證、地理編碼和 Places API，找出現有顧客的地點 ID。
執行空白排除作業：在 BigQuery 中，將 CRM 地點 ID 與 Places Insights 資料合併，動態篩除現有顧客，並輸出新的待開發客戶名單。

必要條件

開始之前，請確認您具備以下項目：

Google Cloud 專案：
- 已啟用計費功能的 Google Cloud 專案。
資料存取權：
- BigQuery 中的Places Insights 訂閱項目。
- 您自己的 CRM 資料集 (例如 BigQuery 資料表)，內含現有客戶的商家名稱和地址，做為排除清單。
Google Maps Platform：
- API 金鑰。
- 金鑰已啟用下列 API：
IAM 權限：
- 請確認使用者或服務帳戶具備下列 IAM 角色，可執行查詢及管理資料集：
  
  角色 ID
  
  BigQuery 資料編輯者 roles/bigquery.dataEditor
  
  BigQuery 使用者 roles/bigquery.user
費用提醒：
- 本教學課程使用 Google Cloud 的計費元件，請注意下列相關的潛在費用：
  - BigQuery：系統會根據查詢執行期間使用的運算單元或處理的資料量計費。
  - Places Insights：根據查詢用量計費。
  - Google Maps Platform：系統會針對 Address Validation API、Geocoding API 和 Text Search API 的要求收費。

角色	ID
BigQuery 資料編輯者	`roles/bigquery.dataEditor`
BigQuery 使用者	`roles/bigquery.user`

步驟 1：定義目標地點類型

Places Insights 支援近 500 個地點類別和超過 70 個屬性 (例如營業時間、付款方式和營運狀態)。不分青紅皂白地查詢整個資料集，效率低落且成本高昂。

首先，請使用 Gemini 等 LLM 將內部客戶設定檔轉換為地點類型，以便在建構 Places Insights 查詢時使用。這個巨觀層級的分類定義可確保後續的 BigQuery 搜尋作業高度精準，進而減少運算處理的負擔。

舉例來說，如果您要設計 POS 系統的工作流程，可以向 Gemini 提供地點類型清單，並使用下列提示詞：

「你是市場分析師。在支援的 Google 地圖地點類型中，銷售點系統供應商的主要目標是哪些類型？請說明你的決定。"

根據這項提示，Gemini 會分析分類架構，並傳回相關地點類型的目標子集，供您在 BigQuery types 篩選器中使用：

主要類別	原因	主要地點類型
餐飲	需要快速處理交易、管理餐桌、開立訂單，以及處理小費。	`restaurant`、`bar`、`cafe`、`coffee_shop`
購物	需要完善的庫存追蹤、條碼掃描、退貨處理和會員整合功能。	`clothing_store`、`grocery_store`、`supermarket`、`convenience_store`
服務和健康與保健	必須整合預約、排程、顧客個人資料和佣金追蹤功能。	`hair_salon`、`beauty_salon`、`spa`、`massage`
娛樂、休閒和運動	必須快速處理顧客湧入、掃描電子票券，並快速銷售點心。	`movie_theater`、`amusement_park`、`bowling_alley`、`stadium`

在本指南中，我們將著重於「餐飲」類別的建議地點類型。

步驟 2：擷取商家數量，找出高潛力區域

如要找出商機領域，首先需要商家密度的巨觀檢視畫面。如要達成這個目標，請在 BigQuery 中執行地點計數函式 (例如 PLACES_COUNT_PER_H3 或 PLACES_COUNT_PER_GEO)。

雖然您可以直接查詢資料集，但 Places Count 函式是預先定義的 SQL 查詢，經過最佳化處理，不會強制執行至少 5 個地點的標準匯總門檻 (標準直接查詢會省略有 1 到 4 個商家的資料列；不過，這些函式可讓您準確查看即使只有單一潛在客戶的地點)。請注意，這些函式會使用 sample_place_ids 資料欄，針對每個地理區域傳回最多 250 個地點 ID 的陣列。這項功能可為區域規劃人員提供統計熱視圖，以及產生待開發客戶所需的基本 ID。

下列查詢示範如何使用公開資料集動態擷取複雜多邊形 (紐約市的整個邊界)，然後將該地理位置傳遞至 Places Count 函式。在整個城市中以較廣泛的解析度 (8) 使用 H3 空間索引，即可產生巨觀層級的密度地圖。

此外，選取所有資料欄 (SELECT *) 時，函式會傳回 geography 資料欄，也就是代表 H3 儲存格的多邊形。這樣一來，您就能立即將 BigQuery 結果匯入商業智慧工具 (例如 Looker Studio)，建立填滿地圖的視覺化效果，以視覺化方式呈現市場熱點。

-- Illustrative logic: Extracting target business counts per H3 cell across New York City
DECLARE geo GEOGRAPHY;

-- Get the geography for New York City using the Overture Maps public dataset
SET geo = (SELECT geometry FROM `bigquery-public-data.overture_maps.division_area`
  WHERE country = 'US' AND subtype = 'locality' AND names.primary = 'New York' LIMIT 1);

SELECT *
FROM `YOUR_PROJECT_NAME.places_insights___us.PLACES_COUNT_PER_H3`(
  JSON_OBJECT(
      'geography', geo,
      'h3_resolution', 8,
      'types',['restaurant', 'bar', 'cafe', 'coffee_shop'],
      'business_status', ['OPERATIONAL']
  )
)
ORDER BY count DESC;

地圖視覺化效果：顯示紐約市上不同不透明度的綠色 H3 六邊形，表示曼哈頓的商家密度很高。

如結果視覺化所示，曼哈頓的目標商家密度明顯較高。在本文的其餘部分，我們將深入探討，並將待開發客戶產生的重心放在其中一個高潛力區域：聯合廣場附近的區域。

步驟 3：將 CRM 資料正規化為地點 ID

如要進行排除分析，請先將 CRM 記錄轉換為地點 ID。由於 CRM 資料通常是非結構化資料，因此將原始文字傳遞至搜尋 API 會導致比對率偏低。使用這個兩步驟管道清理地址、考量區域 API 涵蓋範圍，並確保您為 BigQuery 擷取正確的場所 ID。

假設您在紐約市的客戶關係管理系統中，有下列 5 位餐廳客戶：

地點名稱	地址
Boucherie Union Square	225 Park Ave S, New York, NY 10003, United States
Gramercy Tavern	42 E 20th St, New York, NY 10003, United States
Barn Joo Union Square	35 Union Square W, New York, NY 10003, United States
LOS TACOS No.1	200 Park Ave S, New York, NY 10003, United States
Union Square Cafe	101 E 19th St, New York, NY 10003, United States

由於這些記錄包含非結構化文字，因此您無法在 BigQuery 中直接與 Places Insights 資料彙整。請改為透過下列管道處理每一列，將文字標準化並擷取地點 ID。

步驟 3a：地址清除和直接比對

請先將地址資料標準化，根據目標國家/地區選擇 API：

選項 1：Address Validation API

如要瞭解支援的區域，請將串連的 CRM 商家名稱和地址傳遞至 API。檢查回應的 result.geocode.placeTypes 陣列：

商家比對：如果包含 establishment 或 point_of_interest，表示 API 已成功解析商家。將這個 placeId 附加至資料集，然後移至下一個 CRM 記錄。這個項目不需要進一步的 API 呼叫。
非機構相符：如果沒有這些商家類型，API 就無法明確確認商業主體。傳回的地點 ID 代表地理特徵 (例如建築物、街道或城市)。請勿將這個地點 ID 用於 BigQuery，否則排除條件聯結會失敗。請改為儲存 result.address.formattedAddress，然後前往步驟 3b。

選項 2：Geocoding API

如果地址驗證服務不支援相關區域，請只將 CRM 地址傳遞至 Geocoding API。請勿加入商家名稱，否則 Geocoding API 可能會傳回無法預測的結果。解壓縮產生的 formattedAddress，然後繼續執行步驟 3b。

進階架構：使用 LLM 處理非結構化資料

如果 CRM 資料品質不佳，例如商家名稱和地址混雜在單一自由文字備註欄位中，請使用 Gemini 等 LLM 預先處理記錄。你可以提示 Gemini 從地點中清楚剖析商家名稱，再將這些名稱輸入這個管道。

步驟 3b：解決商家實體問題

如果步驟 3a只傳回經過清除的地址，請將該地址與原始 CRM 商家名稱串連，然後傳遞至 Text Search API。先將地址標準化，可大幅提高媒合率。

如要盡可能提高效能和降低成本，請使用欄位遮罩 (X-Goog-FieldMask: places.id) 並設定 "pageSize": 1，確保只傳回高度相符內容的地點 ID。

文字搜尋要求範例：

curl -X POST -d '{
  "textQuery" : "Gramercy Tavern 42 E 20th St, New York, NY 10003-1324, USA",
  "pageSize": 1
}' \
-H 'Content-Type: application/json' -H 'X-Goog-Api-Key: YOUR_API_KEY' \
-H 'X-Goog-FieldMask: places.id' \
'https://places.googleapis.com/v1/places:searchText'

管道輸出

透過這個兩步驟管道處理 CRM 記錄後，無論是在步驟 3a 中成功擷取 ID，還是在步驟 3b 中使用 Text Search 解決問題，最終目標都是在資料集中附加新的 place_id 欄。現在，您可以將這個產生的資料表上傳至 BigQuery，做為排除條件清單。

地點名稱	地址	地點 ID
Boucherie Union Square	225 Park Ave S, New York, NY 10003, United States	ChIJc1Vf7KFZwokR1YL2Rn9oxi8
Gramercy Tavern	42 E 20th St, New York, NY 10003, United States	ChIJvSQIgqFZwokRFYQbJdzceSs
Barn Joo Union Square	35 Union Square W, New York, NY 10003, United States	ChIJQ7XpyqNZwokRQpVfvGEViWM
LOS TACOS No.1	200 Park Ave S, New York, NY 10003, United States	ChIJFZh0PABZwokRVzoJu0o-mLY
Union Square Cafe	101 E 19th St, New York, NY 10003, United States	ChIJxTHke6JZwokRCLWVd99eDBw

步驟 4：在 BigQuery 中執行空白排除分析

將現有顧客對應至地點 ID 後，即可使用地點計數函式找出全新待開發客戶。

在本範例中，我們將在聯合廣場 (40.73595, -73.99043) 半徑 850 公尺內，搜尋營運目標商家 (餐廳、酒吧、咖啡廳和咖啡店)。為提供更精細的街道層級路線規劃，我們將 PLACES_COUNT_PER_H3 函式的解析度提高至 10。

由於函式會以陣列形式在 sample_place_ids 欄中傳回地點 ID，因此我們必須UNNEST陣列，將每個潛在商家放在各自的資料列中。然後，我們針對已知的顧客地點 ID 執行 LEFT JOIN。

為證明排除邏輯適用於這項示範，下列查詢會使用 CASE 陳述式標記結果，而不是完全篩除結果。此外，系統也會將現有顧客明確排序在結果表格的最上方，方便您確認是否成功比對。

SQL 查詢

WITH existing_customers AS (
  -- 1. Simulate the uploaded CRM table
  SELECT * FROM UNNEST([
    'ChIJc1Vf7KFZwokR1YL2Rn9oxi8', -- Boucherie Union Square
    'ChIJvSQIgqFZwokRFYQbJdzceSs', -- Gramercy Tavern
    'ChIJQ7XpyqNZwokRQpVfvGEViWM', -- Barn Joo Union Square
    'ChIJFZh0PABZwokRVzoJu0o-mLY', -- LOS TACOS No.1
    'ChIJxTHke6JZwokRCLWVd99eDBw'  -- Union Square Cafe
  ]) AS place_id
),

target_area_businesses AS (
  -- 2. Query Places Insights for target businesses in the radius
  SELECT
    h3_cell_index,
    place_id
  FROM `places_insights___us.PLACES_COUNT_PER_H3`(
    JSON_OBJECT(
      'geography', ST_GEOGPOINT(-73.99043, 40.73595),
      'geography_radius', 850,
      'h3_resolution', 10,
      'types',['restaurant', 'bar', 'cafe', 'coffee_shop'],
      'business_status', ['OPERATIONAL']
    )
  ),
  UNNEST(sample_place_ids) AS place_id
)

-- 3. The "Proof" Output: Flag them instead of filtering them out
SELECT
  t.h3_cell_index,
  t.place_id,
  -- Flag whether the LEFT JOIN found a match in the CRM table
  CASE
    WHEN e.place_id IS NOT NULL THEN 'Existing Customer (To Be Excluded)'
    ELSE 'Net-New Lead'
  END AS lead_status,
  CONCAT('https://www.google.com/maps/search/?api=1&query=Place&query_place_id=', t.place_id) AS actionable_maps_url
FROM target_area_businesses t
LEFT JOIN existing_customers e
  ON t.place_id = e.place_id
ORDER BY
  -- Explicitly sort the existing customers to the top (0 comes before 1)
  CASE WHEN e.place_id IS NOT NULL THEN 0 ELSE 1 END ASC;

查詢結果

以下是查詢輸出的摘錄內容，顯示如何成功識別現有顧客，並將其與相同精細 H3 儲存格中的全新待開發客戶分開。

請注意，查詢如何使用 CONCAT 陳述式，透過 place_id 建構跨平台地圖網址。系統會自動產生 actionable_maps_url 欄，為銷售團隊提供可立即點選的連結，在 Google 地圖行動應用程式或瀏覽器中載入確切商家。

`h3_cell_index`	`place_id`	`lead_status`	`actionable_maps_url`
8a2a100d2767fff	ChIJQ7XpyqNZwokRQpVfvGEViWM	現有顧客 (待排除)	https://www.google.com/maps/search/?api=1&query=Place&query_place_id=ChIJQ7XpyqNZwokRQpVfvGEViWM
8a2a100d20effff	ChIJvSQIgqFZwokRFYQbJdzceSs	現有顧客 (待排除)	https://www.google.com/maps/search/?api=1&query=Place&query_place_id=ChIJvSQIgqFZwokRFYQbJdzceSs
8a2a100d2397fff	ChIJc1Vf7KFZwokR1YL2Rn9oxi8	現有顧客 (待排除)	https://www.google.com/maps/search/?api=1&query=Place&query_place_id=ChIJc1Vf7KFZwokR1YL2Rn9oxi8
8a2a100d2397fff	ChIJFZh0PABZwokRVzoJu0o-mLY	現有顧客 (要排除)	https://www.google.com/maps/search/?api=1&query=Place&query_place_id=ChIJFZh0PABZwokRVzoJu0o-mLY
8a2a100d23b7fff	ChIJxTHke6JZwokRCLWVd99eDBw	現有顧客 (要排除)	https://www.google.com/maps/search/?api=1&query=Place&query_place_id=ChIJxTHke6JZwokRCLWVd99eDBw
8a2a1072c96ffff	ChIJ6atD-WRZwokRULgcZ4TWin8	Net-New Lead	https://www.google.com/maps/search/?api=1&query=Place&query_place_id=ChIJ6atD-WRZwokRULgcZ4TWin8
8a2a1072c96ffff	ChIJ09yg-llZwokRKAgp0jg6TCU	Net-New Lead	https://www.google.com/maps/search/?api=1&query=Place&query_place_id=ChIJ09yg-llZwokRKAgp0jg6TCU

使用 Places UI Kit 顯示待開發客戶

您可以將 place_ids 直接傳遞至 Places UI Kit，為銷售團隊建立豐富的內部待開發客戶產生資訊主頁，而不必提供原始的 Maps 網址。適用於各個平台，您可以插入預先建構的元件，用於網站、Android 和 iOS。這些元件會自動顯示豐富的搜尋點資料，例如相片、評分和營業時間，您不必編寫前端 UI 程式碼或手動處理 API 回應。

數據用量上限

地點數量函式在 sample_place_ids 陣列中，每個地理單元最多會傳回 250 個地點 ID。如果特定儲存格的密度極高，系統產生的潛在客戶名單上限為 250 人。如要確保在高度密集的市場中掌握所有待開發客戶，請考慮採用下列策略：

使用特定查詢篩選器：不要將多種型態分組到一個查詢中 (如上例)，請針對每種地點類型分別執行查詢。
縮小空間範圍：使用較小的 geography_radius 縮減整體搜尋範圍，或提高 H3 解析度 (最高可達解析度 11)，將範圍劃分成更小的細微區塊。
依密度調整解析度：分析人口密度不同的區域時，請動態調整搜尋範圍大小，以免達到 250 個地點 ID 的上限。在商家分布較廣的鄉村地區，請使用較廣的 H3 解析度 (例如 6 或 7)，或較大的 geography_radius。反之，在人口密集的市區，請使用精細度較高的解析度 (例如 10 或 11)，確保擷取所有潛在待開發客戶，不會截斷名單。

製作查詢

確認系統已成功識別現有顧客後，即可還原為查詢的正式版。將最後的 SELECT 區塊替換為下列 WHERE 子句，永久篩除現有業務：

SELECT
  t.h3_cell_index,
  t.place_id,
  CONCAT('https://www.google.com/maps/search/?api=1&query=Place&query_place_id=', t.place_id) AS actionable_maps_url
FROM target_area_businesses t
LEFT JOIN existing_customers e
  ON t.place_id = e.place_id
WHERE e.place_id IS NULL; -- Filters out the CRM matches

架構管理與法規遵循

為維持高效能且符合規定的系統，請遵守下列標準：

地點 ID 做為永久 ID：除了地點 ID 之外，Google 地圖服務條款也禁止儲存或快取從 Places API 傳回的個別 POI 資料 (例如電話號碼和聯絡資訊)。請使用地點 ID 做為永久 ID，進行重複的空白空間分析。
透過即時 API 呼叫確保屬性為最新狀態：使用地點 ID 對 Place Details API 進行「即時」呼叫，確保銷售人員擁有地點的最新商家和聯絡資訊。或者，如查詢輸出內容所示，您可以動態建構 Google 地圖網址，為銷售團隊提供 Google 地圖上商家檔案的直接連結。

結論

將地點 ID 標準化為主鍵後，您成功彌合了高階市場分析與可執行的基層銷售作業之間的差距。這項架構可避開傳統以母體為準的目標對象設定所造成的誤差，利用無伺服器資料倉儲進行大量運算聯結，並在 API 層級嚴格遵守成本管理和法規遵循最佳做法。

後續動作

要求存取 Places Insights 範例資料集。
透過 BigQuery 資料交換目錄訂閱 Places Insights 資料集，存取範例或完整國家/地區資料。
請參閱篩選器參數參考資料，根據商家屬性和類型微調 BigQuery SQL 查詢。
在 CRM 或銷售路徑應用程式中導入動態 Places API 查詢，顯示新開發待開發客戶的最新聯絡資訊，確保符合規定。

貢獻者

Henrik Valve | 開發人員體驗工程師