זיהוי לידים חדשים למכירות בשטח באמצעות Places Insights

בדרך כלל, כדי להגדיר את הפוטנציאל של אזור מסוים, עסקים שרוצים ליצור לידים מעסקים אחרים מסתמכים על רכישה של ספריות סטטיות או רשימות של תעשיות. עם זאת, מערכי הנתונים הסטטיים האלה של נקודות עניין (POI) מתיישנים כמעט באופן מיידי. לצוותי מכירות בשטח אין בדרך כלל גישה לסטטוס עדכני של פעילות או לסיווג מפורט של סוג המקום, ולכן הם עלולים לבזבז זמן יקר בניסיון להגיע לעסקים שסגורים לצמיתות, שסווגו בצורה שגויה או שלא רלוונטיים לפרופיל הלקוח האידיאלי.

במדריך הזה מוצג תהליך עבודה לגישור על הפער הזה באמצעות Places Insights ו-Places API. אם תמפו את רשימת העסקים הנוכחית שלכם למזהי המקומות, תוכלו להשתמש ב-BigQuery כדי לבודד כל עסק תפעולי באזור שלא מופיע כבר במסד הנתונים של ניהול קשרי הלקוחות (CRM). במדריך הזה מוסבר איך לבנות את מנוע ההחרגות הזה כדי לספק לנציגי השטח רשימה של לידים מאומתים וממוקדים במיוחד.

דיאגרמה שמציגה נתונים קיימים ממערכת ניהול קשרי לקוחות (CRM) שעברו עיבוד באמצעות Places API ו-Places Insights ב-BigQuery כדי ליצור לידים חדשים מאומתים.

דוגמה לאפליקציה

נניח שספק של נקודות מכירה (POS) מתכנן להרחיב את המכירות בשטח בעיר ניו יורק. בדרך כלל, הארגון יפיק דוח על מספר העסקים הכולל בתחום המזון והמשקאות בכל מיקוד. הגישה הזו עלולה לגרום לכך שנציגי המכירות יסתמכו על נתונים לא עדכניים, כמו מיקומים שנסגרו באופן סופי, או על לידים לא רלוונטיים, כמו מטבח קייטרינג פרטי ללא חזית חנות. במקום זאת, אפשר להשתמש בגישה מודרנית יותר באמצעות Places Insights, שמסתמכת על נתונים עדכניים בקנה מידה גלובלי ממפות Google, שעברו אימות ממקורות שונים. הכלי 'תובנות לגבי מקומות' תומך בכמעט 500 קטגוריות של מקומות ויותר מ-70 מאפיינים, ומאפשר לכם לחדד את רשימת הלקוחות הפוטנציאליים בדיוק גבוה על סמך סוגים ספציפיים של עסקים (כמו scandinavian_restaurant), שעות פעילות ושירותים מוצעים (כמו accepts_credit_cards). על ידי הצלבת נתונים בין הכלי 'תובנות לגבי מקומות' לבין הנתונים במערכת ה-CRM הפנימית שלכם, תוכלו לספק לצוות המכירות רשימה ממוקדת מאוד של לקוחות פוטנציאליים עם פוטנציאל גבוה שלא יצרתם איתם קשר.

תהליך העבודה של הפתרון

במדריך הזה מפורטות הנחיות טכניות ליצירת 'מפת לידים' דינמית שמסננת באופן אוטומטי את הלידים הקיימים שלכם, כך שצוות המכירות יוכל להתמקד רק בלידים חדשים ורלוונטיים.

ארכיטקטורה בת ארבעה שלבים

הגדרת סוגי המקומות לטירגוט: מיפוי של פרופילי הלקוחות האידיאליים לסוגי מקומות.
זיהוי אזורים עם פוטנציאל גבוה: מריצים פונקציות של ספירת מקומות ב-BigQuery כדי ליצור מפות חום של צפיפות של עסקים שהם יעד לפעילות.
נרמול נתוני CRM למזהי מקומות: עיבוד רשומות לא מובנות של CRM באמצעות פייפליין לטיוב נתונים, תוך שימוש ב-API של Address Validation, ב-API של המרת כתובות לקואורדינטות (geocoding) וב-Places API, כדי למצוא את מזהי המקומות של הלקוחות הקיימים.
ביצוע החרגה של רווחים לבנים: מצטרפים למזהי המקומות ב-CRM מול נתוני Places Insights ב-BigQuery כדי לסנן באופן דינמי לקוחות קיימים ולהפיק רשימה של לידים חדשים.

דרישות מוקדמות

לפני שמתחילים, חשוב לוודא שיש לכם:

פרויקט Google Cloud:
- פרויקט ב-Google Cloud שהחיוב בו מופעל.
גישה לנתונים:
- מינוי ל-Places Insights ב-BigQuery.
- מערך נתונים משלכם ב-CRM (למשל, טבלה ב-BigQuery) שמכיל שמות וכתובות של עסקים של לקוחות קיימים, שישמש כרשימת ההחרגות.
Google Maps Platform:
- מפתח API.
- ממשקי ה-API הבאים מופעלים עבור המפתח:
הרשאות IAM:
- מוודאים שלמשתמש או לחשבון השירות יש את תפקידי ה-IAM הבאים כדי להריץ שאילתות ולנהל את מערך הנתונים:
  
  תפקיד מזהה
  
  עריכה של נתוני BigQuery roles/bigquery.dataEditor
  
  משתמש BigQuery roles/bigquery.user
הבנת העלויות:
- במדריך הזה נעשה שימוש ברכיבים של Google Cloud שחלים עליהם חיובים. חשוב להכיר את העלויות האפשריות שקשורות ל:
  - ‫BigQuery: החיוב הוא על משבצות מחשוב שנעשה בהן שימוש או על נתונים שעברו עיבוד במהלך הרצת השאילתה.
  - Places Insights: החיוב מתבצע על סמך השימוש בשאילתות.
  - Google Maps Platform: החיוב הוא לפי בקשה עבור Address Validation API (ממשק API לאימות כתובות), Geocoding API (ממשק API לקידוד גאוגרפי) ו-Text Search API (ממשק API לחיפוש טקסט).

תפקיד	מזהה
עריכה של נתוני BigQuery	`roles/bigquery.dataEditor`
משתמש BigQuery	`roles/bigquery.user`

שלב 1: הגדרת סוגי המקומות לטירגוט

Places Insights תומכת בכמעט 500 קטגוריות של מקומות ויותר מ-70 מאפיינים (כמו שעות פעילות, סוגי תשלום ומצב פעילות). שליחת שאילתות לכל מערך הנתונים באופן לא סלקטיבי היא לא יעילה ויקרה.

כשלב בסיסי, אפשר להשתמש במודל LLM כמו Gemini כדי לתרגם את פרופילי הלקוחות הפנימיים לסוגי מקומות, שמשמשים ליצירת שאילתה ל-Places Insights. הגדרת הטקסונומיה ברמת המאקרו מבטיחה שהחיפושים הבאים ב-BigQuery יהיו ממוקדים מאוד, וכך מצמצמת את התקורה של עיבוד החישובים.

לדוגמה, אם אתם מתכננים תהליך עבודה למערכת קופה, אתם יכולים לספק ל-Gemini את רשימת סוגי המקומות ולהשתמש בהנחיה הבאה:

"תפעל כמנתח שוק. מתוך סוגי המקומות הנתמכים במפות Google, מהם יעדי המיקוד העיקריים של ספק מערכת נקודת מכירה? נמק את ההחלטה שלך".

על סמך ההנחיה הזו, Gemini ינתח את הטקסונומיה ויחזיר קבוצת משנה ממוקדת של סוגי מקומות רלוונטיים לשימוש במסנן types של BigQuery:

קטגוריה ראשית	הצדקה	סוגי מקומות מרכזיים
אוכל ושתייה	העבודה כוללת עיבוד מהיר של עסקאות, ניהול שולחנות, הזמנת כרטיסים וטיפול בטיפים.	`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: חילוץ נתוני ספירת עסקים כדי לזהות אזורים עם פוטנציאל גבוה

כדי לזהות אזורים עם פוטנציאל עסקי, קודם צריך לקבל תמונה רחבה של צפיפות העסקים. כדי לעשות את זה, אפשר להריץ פונקציות של ספירת מקומות (כמו PLACES_COUNT_PER_H3 או PLACES_COUNT_PER_GEO) ב-BigQuery.

אפשר להריץ שאילתה ישירות בקבוצת הנתונים, אבל פונקציות של ספירת מקומות הן שאילתות SQL מוגדרות מראש ומותאמות, שלא מחייבות את הסף לצבירת נתונים הרגיל של 5 מקומות מינימום (שאילתות ישירות רגילות ישמיטו שורות עם עסק אחד עד ארבעה עסקים, אבל הפונקציות האלה מאפשרות לראות בדיוק איפה נמצא אפילו לקוח פוטנציאלי אחד). חשוב לדעת שהפונקציות האלה מחזירות מערך של עד 250 מזהי מקומות לכל אזור גיאוגרפי באמצעות העמודה sample_place_ids. הנתונים האלה מספקים גם מפת חום סטטיסטית למתכנני האזורים שלכם וגם את המזהים הבסיסיים שנדרשים ליצירת לידים.

השאילתה הבאה מדגימה איך לאחזר באופן דינמי פוליגון מורכב (הגבול כולו של העיר ניו יורק) באמצעות קבוצת נתונים ציבורית, ואז להעביר את המיקום הגיאוגרפי הזה לפונקציה Places Count. באמצעות האינדקס המרחבי H3 ברזולוציה רחבה יותר (8) ברחבי העיר, אפשר ליצור מפת צפיפות ברמת מאקרו.

בנוסף, אם בוחרים את כל העמודות (SELECT *), הפונקציה מחזירה את העמודה geography, מצולע שמייצג את תא H3. כך תוכלו לייבא באופן מיידי את התוצאות של BigQuery לכלי בינה עסקית (BI) (כמו 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 ירוקים ברמות שונות של אטימות מעל ניו יורק, שמציינים צפיפות גבוהה של עסקים במנהטן.

כפי שאפשר לראות בהדמיה שמתקבלת, יש אזורים בצפיפות גבוהה של עסקים שמטורגטים במנהטן. בהמשך המסמך הזה, נתמקד באחד מהאזורים האלה עם פוטנציאל גבוה: האזור ליד Union Square.

שלב 3: נרמול נתוני ה-CRM למזהי מקומות

כדי לבצע ניתוח החרגות, קודם צריך לתרגם את הרשומות במערכת לניהול קשרי לקוחות (CRM) למזהי מקומות. נתונים במערכות CRM הם לרוב לא מובנים, ולכן העברת טקסט גולמי לממשקי API של חיפוש מניבה שיעורי התאמה נמוכים. משתמשים בצינור (pipeline) הזה בן שני השלבים כדי לנקות כתובות, להתחשב בכיסוי אזורי של ה-API ולהבטיח שתחלצו את מזהי המקומות הנכונים של המוסדות ל-BigQuery.

נניח שיש לך במערכת CRM את 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. במקום זאת, צריך להריץ כל שורה בתהליך הבא כדי לתקנן את הטקסט ולחלץ את מזהה המקום.

שלב 3א: ניקוי כתובות והתאמה ישירה

קודם צריך לבצע סטנדרטיזציה של נתוני הכתובות. בוחרים את ה-API בהתאם למדינת היעד:

אפשרות 1: Address Validation API

כדי להשתמש ב-API באזורים נתמכים, צריך להעביר ל-API את השם והכתובת של העסק במערכת ה-CRM, כמחרוזת משורשרת. בודקים את מערך result.geocode.placeTypes בתגובה:

התאמה למוסד: אם הערך מכיל establishment או point_of_interest, ה-API הצליח לזהות את העסק. מוסיפים את placeId למערך הנתונים ועוברים לרשומה הבאה במערכת ה-CRM. לא נדרשות קריאות נוספות ל-API עבור הרשומה הזו.
התאמה ללא סניף: אם התוצאה לא מכילה את סוגי העסקים האלה, ה-API לא הצליח לאשר באופן חד משמעי את הישות העסקית. מזהה המקום שמוחזר מייצג תכונה גיאוגרפית (כמו בניין, רחוב או עיר). אל תשתמשו במזהה המקום הזה ב-BigQuery, כי הוא יגרום לכשל בצירופי ההחרגה. במקום זאת, שומרים את result.address.formattedAddress ועוברים לשלב 3ב.

אפשרות 2: Geocoding API

באזורים שלא נתמכים על ידי Address Validation, מעבירים רק את הכתובת במערכת ניהול קשרי לקוחות אל Geocoding API. אל תכללו את שם העסק, כי יכול להיות ש-Geocoding API יחזיר תוצאות בלתי צפויות. מחפשים את התוצאה formattedAddress ועוברים לשלב 3ב.

ארכיטקטורה מתקדמת: טיפול בנתונים לא מובְנים באמצעות מודלים גדולים של שפה (LLM)

אם הנתונים במערכת ה-CRM שלכם באיכות ירודה מאוד, למשל שמות ועסקים וכתובות מעורבבים בשדה הערות יחיד של טקסט חופשי, כדאי לעבד מראש את הרשומות באמצעות מודל שפה גדול (LLM) כמו Gemini. אתם יכולים לתת הנחיה ל-Gemini לנתח את שם העסק מהמיקום בצורה נקייה לפני שמעבירים אותו לפייפליין הזה.

שלב 3ב: פותרים את הבעיה שקשורה לישות העסק

אם שלב 3א מחזיר רק כתובת שעברה ניקוי, צריך לשרשר אותה עם שם העסק המקורי במערכת ה-CRM ולהעביר אותה אל Text Search API. הסטנדרטיזציה של הכתובת קודם לכן משפרת באופן משמעותי את שיעור ההתאמה.

כדי לבצע אופטימיזציה של הביצועים והעלות, משתמשים במסכת שדות (X-Goog-FieldMask: places.id) ומגדירים את "pageSize": 1 כדי להבטיח שיוחזר רק מזהה המקום של ההתאמה הטובה ביותר.

דוגמה לבקשה לחיפוש טקסט:

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 באמצעות פייפליין העיבוד הזה בן שני השלבים, בין אם המזהה חולץ בהצלחה בשלב 3א או נפתר באמצעות חיפוש טקסט בשלב 3ב, המטרה הסופית היא להוסיף עמודה חדשה של place_id למערך הנתונים. עכשיו הטבלה הזו מוכנה להעלאה ל-BigQuery כרשימת ההחרגות שלכם.

שם מקום	כתובת	מזהה מקום
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

אחרי שמתאימים בין הלקוחות הקיימים לבין מזהי המקומות, אפשר להשתמש בפונקציות של ספירת המקומות כדי למצוא את הלידים החדשים.

בדוגמה הזו, נחפש עסקים שהם יעד תפעולי (מסעדות, ברים, בתי קפה) ברדיוס של 850 מטר מיוניון סקוור (40.73595, ‎-73.99043). כדי לקבל תצוגה מפורטת יותר של ניתוב ברמת הרחוב, נגדיל את הפונקציה PLACES_COUNT_PER_H3 לרזולוציה 10.

הפונקציה מחזירה את מזהי המקומות כמערך בעמודה sample_place_ids, ולכן צריך UNNEST את המערך כדי שכל עסק פוטנציאלי יופיע בשורה משלו. לאחר מכן, אנחנו מבצעים 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;

תוצאות השאילתה

הנה קטע מהפלט של השאילתה, שבו אפשר לראות איך הלקוחות הקיימים מזוהים בהצלחה ומופרדים מהלידים החדשים באותם תאים מפורטים ברמה 3 של היררכיית ה-H3.

שימו לב איך השאילתה משתמשת בהצהרה CONCAT כדי ליצור כתובת URL של מפות שפועלת בפלטפורמות שונות, באמצעות 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	ליד חדש	https://www.google.com/maps/search/?api=1&query=Place&query_place_id=ChIJ6atD-WRZwokRULgcZ4TWin8
8a2a1072c96ffff	ChIJ09yg-llZwokRKAgp0jg6TCU	ליד חדש	https://www.google.com/maps/search/?api=1&query=Place&query_place_id=ChIJ09yg-llZwokRKAgp0jg6TCU

תצוגה חזותית של לידים באמצעות Places UI Kit

במקום לספק כתובת URL גולמית של מפות Google, אפשר להעביר את place_ids ישירות אל ערכת כלי הממשק של Places כדי ליצור לוח בקרה פנימי עשיר ליצירת לידים עבור צוות המכירות. התכונה זמינה בכל הפלטפורמות, ואפשר להוסיף את הרכיבים המוכנים מראש לאינטרנט, ל-Android ול-iOS. הרכיבים האלה מציגים באופן אוטומטי נתונים מפורטים של נקודות עניין, כמו תמונות, דירוגים ושעות פעילות, בלי שתצטרכו לכתוב קוד של ממשק משתמש בחלק הקדמי או לטפל בתגובות של ה-API באופן ידני.

מגבלות נתונים

הפונקציות לספירת מקומות מחזירות עד 250 מזהי מקומות לכל תא גיאוגרפי במערך sample_place_ids. אם אזור מסוים צפוף מאוד, רשימת הלידים שנוצרה עבור התא הספציפי הזה תוגבל ל-250. כדי לוודא שאתם מקבלים את כל הלידים בשווקים צפופים מאוד, כדאי להשתמש באסטרטגיות הבאות:

שימוש במסנני שאילתה ספציפיים: במקום לקבץ כמה סוגים בשאילתה אחת (כמו בדוגמה שלמעלה), כדאי להריץ שאילתות נפרדות לכל סוג מקום.
צמצום ההיקף המרחבי: כדי לצמצם את אזור החיפוש הכולל, אפשר להשתמש בgeography_radius קטן יותר או לחלק את האזור למקטעים קטנים יותר ומפורטים יותר על ידי הגדלת הרזולוציה של H3 (עד רזולוציה 11).
התאמת הרזולוציה לפי הצפיפות: כשמנתחים אזורים עם צפיפות אוכלוסייה משתנה, צריך להתאים באופן דינמי את גודל החיפוש כדי לא לחרוג מהמגבלה של 250 מזהי מקומות. באזורים כפריים שבהם העסקים מפוזרים, כדאי להשתמש ברזולוציה רחבה יותר של 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

ניהול ותאימות של ארכיטקטורה

כדי לשמור על מערכת עם ביצועים טובים יותר ותאימות, צריך לפעול לפי הסטנדרטים הבאים:

מזהי מקומות כמזהה עקבי: בנוסף למזהה המקום, התנאים וההגבלות של Google Maps אוסרים לשמור או לאחסן במטמון את הנתונים של כל נקודת עניין שמוחזרים מ-Places API (כמו מספרי טלפון ופרטי קשר).מומלץ להשתמש במזהי מקומות כמזהה עקבי לניתוח חוזר של רווחים לבנים.
איך מוודאים שהמאפיינים עדכניים באמצעות קריאות API בזמן אמת: משתמשים במזהי מקומות כדי לבצע קריאות API של Place Details בזמן אמת, וכך לוודא שלאיש המכירות יש את פרטי העסק ופרטי הקשר העדכניים ביותר לגבי המקום. לחלופין, כפי שמוצג בפלט של השאילתה, אפשר ליצור באופן דינמי כתובות URL של מפות Google כדי לספק לצוות המכירות קישורים ישירים לפרופילי העסק במפות Google.

סיכום

השימוש במזהה המקום כמפתח הראשי מאפשר לכם לגשר בין ניתוח שוק ברמה גבוהה לבין פעולות מכירה ברמת השטח. הארכיטקטורה הזו עוקפת את חוסר הדיוק של טירגוט קונבנציונלי שמבוסס על אוכלוסייה, משתמשת במחסן נתונים בלי שרתים לחיבורים חישוביים כבדים, ומקפידה על שיטות מומלצות לניהול עלויות ותאימות בשכבת ה-API.

הפעולות הבאות

שולחים בקשת גישה למערך הנתונים לדוגמה של Places Insights.
כדי לגשת לנתונים לדוגמה או לנתונים מלאים של מדינה, צריך להירשם למינוי של מערך הנתונים Places Insights באמצעות כרטיסי מוצר ב-BigQuery Data Exchange.
כדאי לעיין בהפניה לפרמטרים של מסננים כדי לשפר את שאילתות BigQuery SQL על סמך מאפיינים וסוגים של עסקים.
כדי לחשוף פרטים עדכניים ותואמים של אנשי קשר עבור לידים חדשים שנוצרו, אפשר להטמיע חיפושים דינמיים ב-Places API במערכת לניהול קשרי לקוחות (CRM) או באפליקציה להפניית מכירות.

תורמים

Henrik Valve | DevX Engineer