בלוג / מדריך מעשי
איך לבנות מאגר משפיענים שנשאר נקי (גיליון או CRM)
רוב רשימות המשפיענים מתחילות כגיליון מהיר והופכות לבלגן תוך רבעון: אותו יוצר מופיע שלוש פעמים תחת שמות משתמש שונים, מספרי העוקבים בני שנה, ואף אחד לא זוכר למה בשורה כתוב "אולי". המדריך הזה מראה איך להקים מאגר משפיענים שנשאר שמיש ככל שהוא גדל, ב-Google Sheets, ב-Airtable, ב-CRM או במסד נתונים אמיתי: רשומה אחת לכל אדם, כל חשבון ברשת שמור בנפרד, כל קישור מנורמל, ותיעוד של מתי ואיך למדתם כל עובדה.
התחילו במטרה של המאגר
לפני שמוסיפים עמודה, כתבו משפט אחד על ההחלטות שהמאגר צריך לתמוך בהן. "למצוא יוצרים לקמפיינים של טיפוח העור שלנו ולעקוב אחרי מי שקיבל תשלום" מוביל לתכנון אחר מאשר "למפות כל יוצר כושר בגרמניה לסקר שוק". המטרה אומרת לכם אילו שדות צריך, באיזו תדירות לרענן אותם, ומה לא לאסוף.
החליטו גם מי ישתמש בו ולפי מה תסננו. יותר משתמשים פירושו כללי עריכה מחמירים יותר, וכל דבר שמסננים לפיו (נישה, מדינה, פלטפורמה, סטטוס) צריך עמודה משלו עם רשימת ערכים קבועה, לא טקסט חופשי.
שורה אחת לכל יוצר, לא לכל חשבון
החלטת התכנון השימושית ביותר היא להפריד בין האדם לבין החשבונות שלו. יוצרת כמו "Maya Okafor" יכולה לנהל את @mayabakes ב-Instagram, את @mayabakes_ ב-TikTok וערוץ YouTube בשם Maya in the Kitchen. אם כל אחד מהם הוא שורה, תשלחו לה מייל שלוש פעמים ותספרו את החשיפה שלה שלוש פעמים.
השתמשו בשתי טבלאות (שתי לשוניות בגיליון, או שני אובייקטים ב-CRM): יוצרים, שורה אחת לכל אדם, וחשבונות, שורה אחת לכל פרופיל ברשת שמצביעה על מזהה יוצר יציב שלא משתנה לעולם, גם אם כל שמות המשתמש משתנים.
טבלת היוצרים
| עמודה | דוגמה | הערות |
|---|---|---|
| creator_id | CR-000142 | יציב, אף פעם לא ממוחזר. אל תשתמשו בשם משתמש כמזהה. |
| display_name | Maya Okafor | איך היוצר מציג את עצמו בפומבי. |
| primary_niche | אפייה | בחרו מרשימה קבועה. |
| country | GB | קוד ISO 3166 בן שתי אותיות שומר על סינון עקבי. |
| business_email | hello@example.com | רק אם פורסם לפניות עסקיות. |
| status | Contacted | ראו את סעיף הסטטוסים בהמשך. |
| owner | Priya | מי בצוות אחראי על הקשר. |
| updated_at | 2026-10-23 | הגדירו אוטומטית אם הכלי מאפשר. |
טבלת החשבונות
| עמודה | דוגמה | הערות |
|---|---|---|
| account_id | AC-000387 | מזהה יציב לשורת החשבון. |
| creator_id | CR-000142 | מקשר לטבלת היוצרים. |
| platform | רשימה קבועה: instagram, tiktok, youtube, x וכן הלאה. | |
| handle | mayabakes | מנורמל: אותיות קטנות, בלי @. |
| platform_user_id | UCxxxxxxxxxxxxxxxxxxxxxx | כשאפשר להשיג אותו. שורד שינויי שם משתמש. |
| canonical_url | https://www.instagram.com/mayabakes/ | נבנה משם המשתמש בפורמט קבוע אחד. |
| followers | 48200 | מספר, לא "48.2K". |
| followers_as_of | 2026-10-20 | התאריך שבו ראיתם את המספר. |
| link_confidence | high | כמה אתם בטוחים שהחשבון שייך ליוצר הזה. |
| link_evidence | קישור מדף ה-About שלה ב-YouTube | למה אתם מאמינים בזה. |
אם אתם מייבאים ומייצאים ב-CSV, השאירו את הכותרות זהות לעמודות כדי ששום דבר לא ישנה שם בדרך:
creator_id,display_name,primary_niche,country,languages,business_email,status,owner,notes,created_at,updated_at
account_id,creator_id,platform,handle,platform_user_id,canonical_url,followers,followers_as_of,link_confidence,link_evidence,sourceנרמלו כל כתובת פרופיל וכל שם משתמש
רוב הכפילויות הן פרופיל אחד שנכתב בדרכים שונות. https://instagram.com/MayaBakes?igsh=abc123, instagram.com/mayabakes/ ו-@mayabakes הם חשבון אחד, אבל הגיליון רואה שלושה ערכים. נרמלו בכניסה, בכל פעם.
- Step 1חיתוך רווחים ואותיות קטנות
הסירו רווחים לפני הערך ואחריו והמירו לאותיות קטנות. שמות משתמש ב-Instagram, ב-TikTok וב-X לא רגישים לרישיות, כך ש-
MayaBakesו-mayabakesהם אותו חשבון. - Step 2הסרת פרמטרי מעקב ותוספות
חתכו את כל מה שאחרי
?או#(קישורי שיתוף מוסיפים לעיתים קרובות פרמטרים כמוigsh,utm_sourceאוis_from_webapp), והסירו את הלוכסן שבסוף. - Step 3חילוץ שם המשתמש
הוציאו רק את שם המשתמש והסירו
@בתחילתו. שמרו אותו בעמודהhandle. דחו קישורים שמצביעים על פוסט, Reel או סרטון (למשל/p/,/reel/או/video/) במקום על פרופיל, או חפשו קודם את פרופיל היוצר. - Step 4בניית כתובת קנונית מחדש
צרו את הכתובת משם המשתמש בפורמט קבוע אחד לכל פלטפורמה. לעולם אל תדביקו את קישור השיתוף המקורי לעמודה הקנונית.
- Step 5בדיקת התאמה קיימת
חפשו בטבלת החשבונות את אותה פלטפורמה ואותו שם משתמש (או מזהה משתמש בפלטפורמה). אם הוא קיים, עדכנו את השורה הזו במקום.
| פלטפורמה | קלט מבולגן | שם משתמש | צורה קנונית |
|---|---|---|---|
| https://Instagram.com/MayaBakes/?igsh=abc123 | mayabakes | https://www.instagram.com/mayabakes/ | |
| TikTok | https://www.tiktok.com/@MayaBakes_?lang=en | mayabakes_ | https://www.tiktok.com/@mayabakes_ |
| X | https://twitter.com/MayaBakes | mayabakes | https://x.com/mayabakes |
| YouTube | https://youtube.com/@MayaInTheKitchen/videos | @mayainthekitchen | https://www.youtube.com/@mayainthekitchen |
ב-YouTube צריך זהירות נוספת: אפשר להגיע לערוץ דרך @handle, דרך כתובת /channel/UC... עם מזהה הערוץ הקבוע, או דרך כתובות ישנות של /c/ ו-/user/. מזהה הערוץ שורד שינויי שם משתמש, אז שמרו אותו ב-platform_user_id והתייחסו אליו כמפתח של שורות YouTube.
ב-Google Sheets אפשר לחלץ את שם המשתמש של Instagram ו-TikTok בנוסחה. כשהקישור הגולמי בעמודה A, הנוסחאות האלה מחזירות שם משתמש באותיות קטנות, או תא ריק כשהקישור לא מתאים:
=IFERROR(LOWER(REGEXEXTRACT(A2, "(?i)instagram\.com/([a-z0-9._]+)")), "")
=IFERROR(LOWER(REGEXEXTRACT(A2, "(?i)tiktok\.com/@([a-z0-9._]+)")), "")בנו את הכתובת הקנונית בעמודה הבאה, למשל ="https://www.instagram.com/" & B2 & "/". נוסחת Instagram תופסת גם קישורים לפוסטים ומחזירה p, אז סננו ערכים כמו p, reel, explore ו-stories ותקנו את השורות האלה ידנית.
הסירו כפילויות, מזגו ותעדו ראיות
אותו אדם, שמות משתמש שונים
Maya היא @mayabakes ב-Instagram ו-@mayabakes_ ב-TikTok, ולכן התאמה לפי שם משתמש בלבד לא תחבר ביניהם. חפשו ראיות שקושרות את החשבונות: קישורים בביו, דף link-in-bio או אתר שמציג את שניהם, אותו מייל עסקי, או חשבון אחד שמזכיר את השני. כשאתם מאשרים התאמה, חברו את שתי שורות החשבון לאותו creator_id.
אותו שם משתמש, אנשים שונים
@jordanruns ב-Instagram ו-@jordanruns ב-X עשויים להיות שני אנשים שאין ביניהם קשר. התייחסו להתאמה בשם משתמש כאל כיוון לבדיקה, אף פעם לא כאל הוכחה.
כשאתם כן ממזגים שתי רשומות יוצר:
- בחרו את ה-
creator_idהוותיק יותר כשורד, כדי שהפניות קיימות ימשיכו לעבוד. - העבירו כל שורת חשבון, הערה ועסקה מהכפיל לשורד.
- שמרו את מזהה הכפיל בעמודת
merged_into(או ביומן מיזוגים קטן) במקום למחוק אותו, כדי שתוכלו לעקוב אחרי ייצואים ישנים. - פתרו סתירות על ידי שמירת הערך המתוארך העדכני ביותר.
תעדו ראיות ורמת ביטחון לכל קישור
הקשר בין אדם לחשבון הוא טענה, וטענות משתבשות. מישהו בצוות בעוד שנה יצטרך לדעת למה האמנתם שחשבון ה-TikTok שייך ל-Maya. שתי עמודות בכל שורת חשבון מכסות את זה: link_confidence ו-link_evidence.
| רמת ביטחון | מה נחשב ראיה | מה לעשות |
|---|---|---|
| גבוהה | היוצר מקשר לחשבון מפרופיל מאומת או מבוסס אחר, או מהאתר שלו. | השתמשו בו לפניות ולדוחות. |
| בינונית | אותו שם, תמונה ונישה, ועוד דף link-in-bio תואם או אזכורים הדדיים, אבל בלי קישור ישיר. | השתמשו בו, אבל בדקו לפני חתימה על עסקה. |
| נמוכה | רק שם משתמש או שם דומים. | השאירו אותו מחוץ לדוחות עד שתאשרו. |
כתבו ראיה שאדם אחר יכול לבדוק, כמו "קישור מדף ה-About ב-YouTube, נבדק ב-2026-10-20", ולא "נראה כמוה". אם כלי מצא את ההתאמה, שמרו את הציון והסיבה שלו, ועדיין בדקו בעצמכם התאמות ברמת ביטחון נמוכה.
שדות למעקב, תאריכי רענון וסטטוס
מספרי עוקבים, מעורבות ואפילו שמות משתמש משתנים, ולכן כל עמודת מדד מקבלת תאריך _as_of תואם. קבעו כלל רענון לכל סוג שדה:
| שדה | משתנה | רענון מומלץ |
|---|---|---|
| עוקבים / מנויים | כל הזמן | לפני כל פנייה או דוח, ובמחזור קבוע, למשל חודשי, ליוצרים פעילים ברשימה. |
| שיעור מעורבות או צפיות ממוצעות | עם כל פוסט | כשמכניסים את היוצר לרשימה הקצרה של קמפיין. תעדו איך חישבתם. |
| שם משתמש וכתובת קנונית | מדי פעם | כשקישור מפסיק לעבוד, ובכל רענון מדדים. מזהי משתמש בפלטפורמה עוזרים כאן. |
| נישה, מדינה, שפה, מייל | לעיתים רחוקות | פעם או פעמיים בשנה, ואת המייל לפני כל סבב פניות. |
| סטטוס והיסטוריית עסקאות | עם כל אינטראקציה | עדכנו ברגע שזה קורה. |
לשדות שאתם מדווחים עליהם, הוסיפו שורות לטבלת metrics_history קטנה (מזהה חשבון, תאריך, עוקבים, צפיות) במקום לדרוס, כדי שתוכלו להראות צמיחה.
השתמשו בצינור סטטוסים פשוט
השתמשו ברשימה נפתחת קצרה והוסיפו תאריך status_changed_at כדי לזהות רשומות שנזנחו. צינור אחד שעובד לרוב הצוותים:
| סטטוס | משמעות |
|---|---|
| Prospect (מועמד) | מתאים לבריף, עוד לא נבדק. |
| Vetted (נבדק) | התוכן, הקהל ובטיחות המותג נבדקו. |
| Contacted (נוצר קשר) | נשלחה הודעה ראשונה. |
| In conversation (בשיחה) | דנים בתנאים. |
| Contracted (בחוזה) | ההסכם נחתם. |
| Live (באוויר) | התוכן פורסם. |
| Completed (הושלם) | סופק ושולם. |
| Not a fit / Declined (לא מתאים / סירב) | נסגר, עם הסיבה. |
| Do not contact (לא ליצור קשר) | ביקשו לא לפנות אליהם. שמרו רק את מה שצריך כדי לכבד את זה. |
יסודות פרטיות למידע על יוצרים
יוצרים הם בני אדם, ומאגר משפיענים הוא מאגר של מידע אישי גם כשכל שדה הגיע מפרופיל ציבורי. זהו מידע כללי, לא ייעוץ משפטי; בדקו עם היועץ המשפטי שלכם את המצב שלכם. כמה עקרונות חלים לפי רוב חוקי הפרטיות, כולל ה-GDPR של האיחוד האירופי ובריטניה וה-CCPA של קליפורניה:
- בסיס חוקי. לפי ה-GDPR, עסקים מסתמכים לעיתים קרובות על אינטרס לגיטימי בפניות עסקיות, כלומר תצטרכו להסביר למה העיבוד נחוץ ולמה הוא לא גובר על האינטרסים של היוצר. תעדו את הנימוק.
- אספו רק מידע ציבורי ורלוונטי. הצטמצמו למה שהיוצר מפרסם למטרות מקצועיות. לעולם אל תשמרו כתובות מגורים או פרטים על המשפחה.
- כבדו את תנאי הפלטפורמות. פלטפורמות רבות אוסרות גריפה אוטומטית (scraping) בלי רשות, אז העדיפו ממשקי API רשמיים, מחקר ידני או כלים שמשתמשים בגישה מותרת.
- ידעו אנשים וכבדו בקשות. ה-GDPR מחייב בדרך כלל ליידע אנשים על מידע שנאסף ממקורות אחרים, לכל המאוחר בפנייה הראשונה. כשיוצר מבקש לראות או למחוק את המידע שלו,
creator_idאחד מאפשר למצוא כל שורה שעוסקת בו. - מחקו את מה שכבר לא צריך. קבעו כלל שמירה, למשל מחיקת מועמדים שמעולם לא פניתם אליהם אחרי תקופה מוגדרת, והפעילו אותו.
- הגבילו גישה. תנו הרשאות עריכה רק למי שצריך.
גיליון, CRM או מסד נתונים: מתי לעבור
| אפשרות | מתאים ל | סימנים שגדלתם ממנו |
|---|---|---|
| גיליון | צוות קטן וכמה אלפי יוצרים. | קישור בין לשוניות לפי מזהה נעשה מסורבל, או שאנשים דורסים זה את זה. |
| מסד נתונים ללא קוד (Airtable ודומיו) | טבלאות מקושרות, רשימות נפתחות ותצוגות בלי קוד. | הגעתם למגבלות של רשומות או אוטומציות. |
| CRM | פניות, תיעוד מיילים, משימות ושלבי עסקה לצוות. | אתם צריכים ניתוח מותאם, או שה-CRM נלחם בהפרדה בין אדם לחשבון. |
| מסד נתונים SQL (Postgres ודומיו) | מערכי נתונים גדולים, מחקר, אפליקציות וגישת API. | קשה לגדול ממנו, אבל צריך מישהו שיתחזק אותו. |
מה שלא תבחרו, שמרו על אותן שתי טבלאות ואותם מזהים. כך מעבר ל-CRM או למסד נתונים בהמשך יהיה ייבוא, לא בנייה מחדש.
למלא את טבלת החשבונות מהר יותר
מציאת החשבונות האחרים של כל יוצר היא בדרך כלל החלק האיטי ביותר בבניית טבלת החשבונות. sociallinks.dev מקבל כתובת פרופיל אחת של Instagram, TikTok, YouTube או X ומחזיר את החשבונות של היוצר בפלטפורמות אחרות, עם ציון ביטחון והראיות לכל התאמה, וזה מתמפה ישירות לעמודות link_confidence ו-link_evidence שלמעלה. מצב העבודה בכמות מקבל עד 500 קישורי פרופיל ומחזיר גיליון.
שאלות נפוצות
אילו עמודות צריכות להיות במאגר משפיענים?
לכל הפחות, טבלת יוצרים עם מזהה יוצר יציב, שם, נישה, מדינה, דרך יצירת קשר, סטטוס ואחראי, ועוד טבלת חשבונות עם פלטפורמה, שם משתמש מנורמל, כתובת קנונית, מספר עוקבים והתאריך שבו תיעדתם אותו. הוסיפו עמודות של רמת ביטחון וראיות לכל קישור חשבון.
איך נמנעים ממשפיענים כפולים בגיליון?
נרמלו כל קישור פרופיל לפני שמוסיפים אותו: אותיות קטנות, בלי מחרוזות שאילתה ולוכסנים בסוף, חילוץ שם המשתמש ובניית כתובת קנונית אחת. ואז בדקו בטבלת החשבונות אם יש כבר אותה פלטפורמה ואותו שם משתמש לפני שמוסיפים שורה. לאותו אדם עם שמות משתמש שונים, קשרו את החשבונות למזהה יוצר אחד על סמך ראיות כמו קישורים בביו.
גיליון או CRM לניהול משפיענים?
גיליון מספיק לצוות קטן ולכמה אלפי יוצרים, כל עוד משתמשים במזהים ובלשוניות נפרדות ליוצרים ולחשבונות. עברו ל-CRM כשצוות צריך תיעוד מיילים משותף ושלבי עסקה, ולמסד נתונים לניתוח בקנה מידה גדול או לגישת API.
כל כמה זמן לעדכן מספרי עוקבים?
רעננו אותם לפני כל פנייה או דוח, ובמחזור קבוע, למשל חודשי, ליוצרים שאתם שוקלים באופן פעיל. תמיד שמרו את התאריך ליד המספר. אי אפשר לסמוך בדוח על מספר עוקבים בלי תאריך.
האם מותר לשמור מידע על משפיענים?
בדרך כלל אפשר לשמור מידע ציבורי ומקצועי על יוצרים, אבל חוקי פרטיות כמו ה-GDPR וה-CCPA עדיין חלים עליו כמידע אישי. בדרך כלל צריך בסיס חוקי, לאסוף רק את מה שנחוץ, ליידע אנשים כשנדרש ולכבד בקשות מחיקה. זה לא ייעוץ משפטי, אז בדקו את הכללים שחלים על העסק שלכם.
מה עושים כשיוצר משנה את שם המשתמש שלו?
השאירו את מזהה היוצר ומזהה החשבון כפי שהם, ועדכנו את שם המשתמש והכתובת הקנונית בשורת החשבון הקיימת. אם שמרתם את מזהה המשתמש של הפלטפורמה, כמו מזהה ערוץ YouTube, השתמשו בו כדי לוודא שזה אותו חשבון. רשמו את שם המשתמש הישן בשדה היסטוריה כדי שייצואים ישנים עדיין יהיו מובנים.