ניתוח מצטבר של ביקורות מתחרים: מה הממשקים הרשמיים באמת מחזירים, למה לא שומרים טקסט ביקורת או שם אדם, ואיך הופכים נושא חוזר להשערת שירות שאפשר לבדוק אצלכם.
עיקרי הדברים
- התוצר של הניתוח הוא נושא וספירה, לא ציטוט. ביקורות הן תוכן שכתבו אנשים, ולעיתים קרובות מוזכר בהן עובד בשמו.
- ממשק Places של Google מחזיר לכל מקום חמש ביקורות לכל היותר, וגם אותן אסור לאחסן: המדיניות אוסרת שמירה מראש ומטמון של תוכן, למעט `place_id`.
- לכן "מחסן ביקורות של מתחרים" אינו תכנון זמין. מה שכן זמין הוא סְפִירה נגזרת שאתם מייצרים ואינה שומרת את הטקסט.
- הביקורות של העסק שלכם עצמכם נגישות בממשק Business Profile דרך `accounts.locations.reviews.list`, וזהו המקור היחיד שבו יש לכם קורפוס מלא ומורשה.
- פער שירות אינו ממצא עד שהוגדרה לו בדיקה על העסק שלכם - מדידה, לקוח סמוי, או שאלה בסקר.
ניתוח ביקורות של מתחרים מייצר דבר אחד שימושי: רשימת נושאים שחוזרים על עצמם, עם ספירה. התוצר אינו ציטוט ואינו תיק על עסק אחר, אלא השערה על השירות שלכם שאפשר לבדוק - למשל "זמן המתנה למענה טלפוני הוא מה שאנשים מתלוננים עליו בקטגוריה".
מה התוצר של הניתוח, ומה הוא אינו
התוצר הוא טבלת נושאים: נושא, מספר האזכורים, שיעור מתוך הביקורות שנקראו, וכיוון הסנטימנט. שורה נראית כך: "המתנה למענה - 19 אזכורים מתוך 140 ביקורות שנקראו, 86 אחוזים מהם שליליים".
מה שאינו חלק מהתוצר, ולא מטעמי טעם אלא כהחלטת תכנון:
- ציטוט מילולי של ביקורת, קצר או ארוך.
- שם המבקר, התמונה שלו, או קישור לפרופיל שלו.
- שם עובד שהוזכר בביקורת, גם כשהוא מופיע במקור בגלוי.
- כל פרט שמאפשר לזהות אדם: תיאור אירוע יחיד, תאריך ביקור מדויק, מספר הזמנה.
- "דוח מתחרה" שמורכב מהעתקת התוכן שלהם עם עיצוב אחר.
הכלל שקל ליישם: אם שורה בתוצר אינה שורדת החלפה של כל שם באות, היא אינה שורה מצטברת. ניתוח מצטבר של ביקורות ככלי עבודה מפורק גם בניתוח ביקורות לקוחות בעזרת בינה מלאכותית.
מה הממשקים הרשמיים באמת מחזירים?
כדאי לדעת את המספרים לפני שמתכננים, כי הם קובעים מה בכלל אפשר:
| מקור | מה מוחזר | המגבלה המהותית |
|---|---|---|
Places API - שדה reviews[] | רשימת ביקורות על המקום, ממוינת לפי רלוונטיות | חמש ביקורות לכל היותר לכל מקום |
Places API - rating | דירוג בין 1.0 ל-5.0 | ממוצע בלבד, לא התפלגות לפי כוכבים |
Places API - userRatingCount | מספר הביקורות הכולל, עם טקסט ובלעדיו | מספר, בלי פילוח לפי זמן |
Places API - reviewSummary | תקציר שנוצר בבינה מלאכותית מתוך ביקורות המקום | מגיע עם טקסט גילוי, ואינו הנתון הגולמי |
| מדיניות Places | place_id פטור ממגבלות המטמון | שאר התוכן - אסור לשמור מראש או במטמון |
| Business Profile API | accounts.locations.reviews.list על מקום שאתם מנהלים | דורש הרשאת OAuth ורק על העסקים שלכם |
שתי מסקנות. ראשונה: userRatingCount מספר לכם כמה ביקורות יש, ו-reviews[] נותן עד חמש - כלומר המרחק בין מה שקיים לבין מה שנגיש הוא מובנה ולא תקלה. שנייה: place_id הוא המזהה היחיד שמותר לשמור לאורך זמן, ולכן הוא העוגן הנכון לרשימת המקומות שאתם עוקבים אחריהם.
איך מנתחים בלי לשמור את הטקסט
המבנה שעובד הוא צינור שמעבד ומשליך, ולא צינור שאוגר:
- שומרים רשימת
place_idשל המקומות שאתם משווים אליהם. זה מה שנשמר לצמיתות. - בכל הרצה קוראים את מה שהממשק מחזיר, בזיכרון בלבד.
- מסווגים כל פריט לנושא מתוך רשימת נושאים קבועה שהגדרתם מראש - למשל מענה, זמן המתנה, מחיר, איכות, נקיון, אמינות מועד.
- סופרים לפי נושא וכיוון סנטימנט, ומייצרים שורות מצטברות.
- משליכים את הטקסט ואת כל מה שמזהה אדם. מה שנשאר הוא מונים.
- שומרים רק את הספירות, יחד עם
place_id, תאריך ההרצה ומספר הפריטים שנקראו.
השלב שאנשים מדלגים עליו הוא הרביעי, ובלעדיו נוצר קורפוס שיושב אצלכם בלי סיבה. הרצה שמסתיימת עם מונים בלבד היא גם הרבה יותר קלה להסביר לכל מי ששואל מה בדיוק אתם מחזיקים.
מנושא חוזר להשערה שאפשר לבדוק
| נושא חוזר אצל מתחרים | מה זה מרמז | השערה לגבי העסק שלכם | איך בודקים אצלכם |
|---|---|---|---|
| "לא חוזרים אליי" | מענה ראשוני איטי בקטגוריה | ייתכן שגם אצלכם זמן המענה ארוך מהמצופה | מודדים זמן עד מענה ראשון על פניות השבוע |
| "המחיר שהוצג לא היה המחיר הסופי" | שקיפות תמחור חלשה | הצעת המחיר שלכם עשויה להשאיר עמימות | קוראים חמש הצעות אחרונות ומסמנים כל סעיף שאינו חד |
| "לא הגיעו במועד" | אמינות מועדים | אולי אתם מבטיחים מועד שאינו נשלט | משווים מועד שהובטח מול מועד בפועל בעשרה מקרים |
| "לא ידעו לענות לי" | ידע לא אחיד בקו הראשון | ייתכן שאין תשובה כתובה לשאלות נפוצות | סופרים כמה פניות הועברו הלאה בחודש |
| "אחרי המכירה נעלמו" | חולשה בשירות לאחר מכירה | אין תהליך מוגדר לאחר סגירה | בודקים אם קיימת נקודת מגע מתוזמנת אחרי אספקה |
העמודה הרביעית היא כל ההבדל בין מסמך מודיעין לבין שיפור. נושא בלי בדיקה נשאר דעה, ובדיקה מייצרת מספר שאפשר לחזור אליו בעוד רבעון. הצעד הבא, ניסוח תגובה ותהליך מול הביקורות שלכם, נדון בתגובות לביקורות בעזרת בינה מלאכותית.
מה ניתוח כזה אינו יכול לומר לכם?
- הוא אינו מייצג את כלל הלקוחות. כותבים ביקורת בעיקר מרוצים מאוד או מאוכזבים מאוד. האמצע כמעט אינו מיוצג.
- דירוג ממוצע אינו איכות שירות. עסק עם 4.6 ו-2,000 ביקורות ועסק עם 4.6 ועשרים ביקורות אינם אותו דבר, והממוצע לבדו מסתיר את זה.
- הוא אינו מזהה ביקורות מוטות. אין דרך אמינה מבחוץ להבחין בין ביקורת אותנטית לבין ביקורת מגויסת.
- חמש ביקורות אינן מדגם. דירוג לפי רלוונטיות אינו דגימה אקראית, ולכן הספירה שלכם מוטה לפי מה שהממשק בחר להציג.
- הוא אינו מסביר סיבה. נושא חוזר מצביע על היכן לחפש, לא על מה קרה.
לכן מספר הפריטים שנקראו הוא חלק מהתוצר עצמו, ולא הערת שוליים. שורה שכתוב לידה "מתוך 140 פריטים שנקראו" ניתנת לביקורת; שורה בלי המספר הזה נראית כמו עובדה על השוק.
להשוות אל מול הביקורות שלכם
הצד השני של הניתוח הוא היחיד שבו יש לכם קורפוס מלא ומורשה: הביקורות של העסק שלכם. ממשק Business Profile מאפשר לקרוא את הביקורות של מקום שאתם מנהלים דרך accounts.locations.reviews.list, לאחר הרשאת OAuth, ומאפשר גם להשיב עליהן.
מכאן ההשוואה שמייצרת ערך: אותם נושאים בדיוק, מסווגים באותה רשימה, פעם על הביקורות שלכם ופעם על מה שנקרא אצל המתחרים. נושא שחזק אצלם וחלש אצלכם הוא יתרון שכדאי לומר אותו בשיווק; נושא שחזק בשני הצדדים הוא בעיה של הקטגוריה. איסוף הביקורות שלכם מכמה פלטפורמות למקום אחד מתואר באיחוד ביקורות Google ופייסבוק.
מקורות
שאלות נפוצות
אפשר לבנות מאגר של כל ביקורות המתחרים?
לא במסלול הרשמי. שדה `reviews[]` בממשק Places מחזיר חמש ביקורות לכל היותר לכל מקום, והמדיניות אוסרת שמירה מראש או מטמון של תוכן הממשק, למעט `place_id` שפטור מהמגבלה. תכנון שמניח מאגר מלא של ביקורות מתחרים אינו מתיישב עם המסלול הזה.
מותר לצטט ביקורת של מתחרה במצגת פנימית?
זה כבר לא נושא של ניתוח מצטבר אלא שימוש בטקסט שכתב אדם על עסק אחר, ולעיתים קרובות גם על עובד ששמו מופיע. השיטה המתוארת כאן אינה כוללת ציטוט, גם לא פנימי, מפני שהתוצר השימושי הוא הספירה ולא המשפט.
מה עושים כשמספר הביקורות שנקראו קטן מדי?
מדווחים עליו. שורה שנשענת על שנים-עשר פריטים אינה ממצא, והדרך הנכונה להציג אותה היא עם המונה לצידה. אם צריך בסיס רחב יותר, מרחיבים את מספר המקומות שנבדקים בקטגוריה במקום להסיק מסקנה חזקה ממדגם קטן.
איך משווים עסק עם אלפי ביקורות לעסק עם עשרות?
לא בממוצע. משווים בשיעורים - כמה אחוזים מהפריטים שנקראו הזכירו נושא מסוים - ומציגים תמיד את מספר הפריטים שנקרא לכל צד. השוואת ממוצעי דירוג בין שני עסקים בסדרי גודל שונים היא הטעות הנפוצה ביותר בניתוח כזה.
להמשך קריאה
שירות רלוונטי
אינטגרציות
לגרום למערכות שאתם כבר משלמים עליהן לדבר זו עם זו.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.