ניהול screenshots וראיות לאוטומציה של פייסבוק ב־2026

אחד הפיצ'רים שלקוחות של BuzzPost שואלים עליו הכי פחות — אבל אחד שבאמת מציל חשבונות — הוא pipeline של forensic logging: כל פעולה של הבוט נשמרת עם screenshot ו־DOM dump. במאמר הזה אסביר למה זה חיוני, מה בדיוק נשמר, כמה זמן להחזיק, ואיך זה משמש כשחשבון נחסם ואתה צריך להגיש ערעור.

אם אתה בונה את הבוט שלך — זה כלי כפי שאתה עוד לא מבין שאתה צריך, עד שיום אחד פייסבוק חוסמת חשבון שווה 50,000₪ ואתה לא יכול להוכיח שלא הפרת אף כלל. עם evidence trail — אתה יכול.

מה זה evidence trail?

הרעיון פשוט: כל פעם שהבוט עושה משהו, הוא שומר עדות לזה. screenshot + DOM dump + timestamp + metadata. כל הדאטה הזה נכנס לתיקייה ייחודית של החשבון, ונשמר ל־60-90 ימים.

למה? כי מתי שאתה צריך evidence, אתה צריך אותו מיד. אם החשבון נחסם ב־5 לחודש, ואתה גילית את זה ב־7, ועד שאתה מוכן להגיש ערעור עברו 3 ימים נוספים — אם לא שמרת evidence באופן רציף, אתה לא יכול להחזיר את הזמן. ה־UI של פייסבוק כבר לא מציג את אותם screens.

סוגי evidence שאנחנו שומרים

1. Successful post evidence

כל פוסט מוצלח שומר:

• {slug}_success_{timestamp}.png — screenshot של הפיד מיד אחרי הפוסט (מראה את הפוסט בפועל).
• {slug}_success_{timestamp}.txt — DOM dump.
• {slug}_success_{timestamp}.json — metadata: group ID, post text, timing, photo hash.

אורך החיים: 30 ימים. אחרי זה נמחק (כי יש הרבה — בוט עם 20 פוסטים ביום שם 600 פוסטים בחודש).

2. Rate-limit evidence

אם הבוט זיהה rate-limit, הוא שומר:

• _rl_evidence/rl_{timestamp}.png — screenshot של הדיאלוג עם השגיאה.
• _rl_evidence/rl_{timestamp}.txt — DOM של הדיאלוג, כולל מבנה הכפתורים.
• _rl_evidence/rl_{timestamp}.json — metadata: זמן הפוסט שגרם, ספירת פוסטים בשעה האחרונה.

אורך החיים: 90 ימים. למה יותר? כי rate-limit הוא signal של פעילות בלתי־רגילה ופייסבוק עלולה לבדוק את ה־history אחורה.

3. Group restriction evidence

אם קבוצה מסוימת מסרבת לפרסם, הבוט שומר:

• grouprestrict_{group_id}_{timestamp}.png
• grouprestrict_{group_id}_{timestamp}.txt

אחרי 5 כשלים רצופים על אותה קבוצה, הבוט מוסיף אותה ל־blacklist ו־5 הראיות נשמרות לצורך הוכחה שניסה.

4. Button disabled evidence

מקרה ספציפי: לפעמים הכפתור "פרסם" נשאר disabled לזמן ארוך (חשד ל־throttling פנימי של פייסבוק). אצלנו:

• btndisabled_{timestamp}.png
• btndisabled_{timestamp}.txt

אם זה קורה 3 פעמים ברצף, פסילה ל־45 דקות.

5. Checkpoint evidence

אם פייסבוק דורשת אימות זהות, screenshot מלא + DOM. השמירה היא permanent (אורך חיים אינסופי) עד שהמשתמש מנקה ידנית.

איך זה משמש לערעור?

בואו נדמיין תרחיש: לקוח שלך מקבל הודעה מפייסבוק "החשבון שלך נחסם בגלל פעילות חריגה". הוא רוצה לערער. מה הוא צריך להגיש?

1. הוכחה שהפעילות הייתה לגיטימית: הפוסטים היו נדל"ן אמיתי, לא ספאם. ה־screenshots המוצלחים מראים את התוכן.
2. הוכחה שלא הפר rate-limits: ה־_rl_evidence מראה כמה פוסטים ביום בממוצע ועם איזה fingerprint.
3. הוכחה שהוא ניסה לכבד את ה־guidelines: כשפייסבוק הגבילה קבוצה, הוא הפסיק לנסות.

עם evidence trail בידי, הסיכוי להחזרת חשבון גדל מ־~10% (בלי) ל־~40%. זה הבדל מהותי.

איפה נשמרים הקבצים?

אצלנו ב־BuzzPost הקבצים נשמרים מקומית על ה־VDS, ב־C:\Users\Administrator\AppData\bot_chrome_profile\evidence\. גיבויים יומיים נעלים ל־cloud storage מוצפן (S3-compatible). אם השרת קורס, ה־evidence עדיין שם.

חישוב מקום: כל screenshot ~150-200 KB, כל DOM dump ~50-100 KB. ל־20 פוסטים ביום זה ~5-7 MB ביום, ~150-200 MB בחודש. ב־3 חודשי שמירה — ~500 MB לחשבון. זה זול.

פורמט screenshot

אנחנו משתמשים ב־PNG עם compression level 6. למה לא JPEG? כי לטקסט אנחנו רוצים חדות, וה־PNG עם הציור של הדיאלוג נקרא בקלות. JPEG מטשטש פיקסלים — לא טוב לראיות מסך.

גודל ה־screenshot: viewport מלא, 1366×768. אנחנו לא חוסכים על איכות — הראיה צריכה להיות ברורה במשפט.

פורמט DOM dump

DOM dump הוא הקובץ .txt שמכיל את ה־outerHTML של document.body ברגע ה־screenshot. הוא תופס יותר מקום מ־screenshot אבל הוא הכרחי כי:

• הוא מאפשר ניתוח אוטומטי אחרי הפעולה.
• הוא מכיל את כל ה־ARIA attributes שהשתמשנו בהם לזיהוי outcome.
• הוא chronicles גם אלמנטים שלא היו visible (זה בא לעזרה כשפייסבוק שולחת alert שהיא חוסמת).

הקוד שלנו:

def save_evidence(driver, evidence_type, slug):
    ts = datetime.now().strftime("%Y%m%d_%H%M%S")
    base = f"_rl_evidence/{evidence_type}_{slug}_{ts}"
    driver.save_screenshot(f"{base}.png")
    with open(f"{base}.txt", "w", encoding="utf-8") as f:
        f.write(driver.execute_script("return document.body.outerHTML;"))
    with open(f"{base}.json", "w") as f:
        json.dump({
            "ts": ts, "slug": slug, "url": driver.current_url,
            "type": evidence_type, "title": driver.title
        }, f)

מתי למחוק?

הוראות retention שלנו:

מחיקה אוטומטית רצה כל יום ב־03:00. כל הקבצים שעברו את ה־TTL נמחקים.

פרטיות והגנת מידע

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

אצלנו ב־BuzzPost:

• הראיות מוצפנות AES-256 ב־rest.
• גישה רק עם 2FA דרך RDP.
• אפילו טכנאי BuzzPost לא רואה את התוכן בלי הסכמה מפורשת של הלקוח.
• מחיקה ידנית של ראיות אפשרית בכל עת דרך הפאנל.

סיכום

evidence management נשמע משעמם, אבל הוא המבטח שיוצא לך מ־5,000₪/חודש של VDS למשהו שמחזיר את ההשקעה כשמשהו משתבש. BuzzPost שומר evidence trail אוטומטית לכל לקוח, עם retention חכם, הצפנה, וגישה דרך הפאנל.

אם אתה רוצה להתחיל לפרסם נדל"ן עם evidence trail מלא — קנה את התוכנית הראשונה ב־249₪ לחודש. למידע נוסף ראה תכונות, rate-limit engineering, אנטי־דטקציה.

נספח: מה לעשות אם חשבון נחסם

1. הפסק מיד את הבוט. אל תנסה login נוסף.
2. בקש מ־BuzzPost את כל ה־evidence לחשבון. הוא יכלול 60-90 ימים אחרונים.
3. הגש ערעור בפייסבוק דרך ה־help center, צרף screenshot של activity לגיטימי.
4. חכה. ערעורי פייסבוק לוקחים 1-30 ימים.
5. אם אושר — שלח ל־BuzzPost כדי שנחזיר את ה־VDS לפעולה.
6. אם נדחה — חשבון אבוד. פתח חשבון חדש (3 שבועות חימום) עם VDS חדש.

שאלות עומק: למה לא לשמור רק "מה שצריך"?

שאלה לגיטימית של מפתחים: למה לשמור 600 screenshots של פוסטים מוצלחים בחודש? הם תופסים מקום, ואף אחד לא יסתכל עליהם.

שלוש סיבות:

1. הוכחת volume. כשמגישים ערעור, פייסבוק רוצה לראות שהחשבון פעיל באמת. 600 screenshots של פוסטים בחודש הם הוכחה שהחשבון בשימוש פעיל ולא bot dormant.
2. baseline לpattern detection. אם החשבון נחסם פתאום, אפשר להסתכל ב־screenshots של ה־24 שעות לפני זה ולמצוא דפוס יוצא דופן (פוסט עם תוכן בעייתי, קבוצה שדיווחה, וכו'). בלי screenshots — אתה עיוור.
3. debugging עתידי. אם פייסבוק מוסיפה מנגנון חדש (שזה קורה כל 2-3 חודשים), screenshots הם הדאטה היחיד שלך לבנות detector חדש.

דחיסה ואופטימיזציה

אם 500 MB לחודש לחשבון נשמע יותר מדי, יש שתי אופטימיזציות שהשתמשנו בהן בעבר:

• crop של ה־screenshot לאזור הרלוונטי. במקום screenshot מלא של 1366×768, חיתוך ל־dialog בלבד (אם רלוונטי). חוסך ~70%.
• דחיסה של DOM dumps עם gzip. ה־HTML גדול אבל מאוד חוזר על עצמו, gzip מוריד ל־~10% מהגודל.

אצלנו בחרנו לא לעשות אופטימיזציה אגרסיבית, כי 500 MB לחודש = 1.50₪ ב־cloud storage. לא שווה את הסיכון של איבוד מידע ב־compression שגוי.

זיהוי anomalies ב־evidence trail

תכונה מתקדמת: הפאנל מנתח את ה־evidence trail אוטומטית ומציין anomalies. למשל:

• אם פתאום יש 5+ rate-limits ב־24 שעות (לעומת ממוצע 0-1).
• אם פתאום יש 3+ checkpoint events ב־שבוע.
• אם אחוז הפוסטים המוצלחים יורד מתחת 80% (לעומת 95% רגיל).

כל aspect כזה יוצר alert קריטי, ואז ה־engineer של BuzzPost יכול לבדוק לפני שהחשבון נחסם לחלוטין.

סטנדרטים פתוחים מול פורמטים קוסטמיים

החלטה פילוסופית שעשינו מוקדם: כל ה־evidence בפורמטים פתוחים שאתה יכול לקרוא עם כלים סטנדרטיים. PNG ל־screenshots, plain text ל־DOM, JSON ל־metadata. שום proprietary binary blobs.

למה? כי אם בעוד 5 שנים BuzzPost כבר לא קיים, או שאתה עובר לספק אחר, ה־evidence שאספת חייב להמשיך לעבוד. PNG ו־JSON יישארו קריאים גם ב־2031. פורמט בינארי custom .bpx של חברה שכבר לא קיימת? אולי לא.

זה חלק מההתחייבות שלנו לבעלות לקוח על דאטה. המערכת היא של BuzzPost, אבל ה־evidence הוא שלך.

שילוב עם ניטור Telegram

בכל פעם ש־evidence נשמרים, אם זה אירוע חריג (rate-limit, checkpoint, group restriction של אחרי 5 כשלים), הבוט גם שולח התראה ל־Telegram עם תמונה מצורפת של ה־screenshot. זה מאפשר ללקוח לראות בעין מה קרה, גם בלי להתחבר ל־VDS.

פורמט ההודעה: "VDS #3 — checkpoint detected at 03:14:22 — see attached screenshot. Bot stopped. Manual intervention needed." ואז התמונה מוצמדת. הלקוח רואה את זה בטלפון ויכול להגיב מיד.

הגנת ראיות מפני tampering

שאלה משפטית: אם אני מציג screenshot לערעור, איך פייסבוק יודעת שלא ערכתי אותו? התשובה: ב־BuzzPost ה־screenshots חתומים עם HMAC-SHA256 ברגע השמירה. אם מישהו ערך את התמונה, ה־hash שלה לא יתאים.

זה לא הוכחה לבית משפט (פייסבוק לא מקבלת רק את ה־HMAC שלנו), אבל זה signal פנימי שהראיות שלך לא נפגעו. אם אי פעם תצטרך להוכיח שה־evidence אותנטי, אתה יכול להראות שה־HMACs מתאימים.

סיפור אמיתי מ־2025

בפברואר 2025 לקוח שלנו, מתווך נדל"ן בקריות, קיבל ban על חשבון בן 4 שנים אחרי 8 חודשים של פעילות עם BuzzPost. הסיבה: "פעילות חשודה". הוא רצה לערער. אספנו את ה־90 ימים של evidence ושלחנו לו:

• 1247 screenshots של פוסטים מוצלחים — תיעוד מלא של פוסטי נדל"ן לגיטימיים.
• 4 evidence files של rate-limits — מראה שכשפייסבוק הגבילה, הבוט עצר מיד.
• 12 evidence files של group restrictions — קבוצות שלא איפשרו פרסום.
• 0 checkpoint events — חשבון לא קיבל אזהרות לפני ה־ban.

הוא הגיש ערעור עם 50 screenshots ב־zip. אחרי 14 ימים פייסבוק החזירה את החשבון עם הודעה "אנחנו מתנצלים, החסימה הייתה שגיאה". בלי ה־evidence trail, החשבון היה אבוד.

שאלות אבטחה מתקדמות

"מה אם פייסבוק תבקש את ה־evidence מ־BuzzPost ישירות?"

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

"האם evidence יכול לשמש נגדי?"

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

מסקנה

evidence trail הוא לא feature נחמדה — הוא תנאי מקדים לאוטומציה אחראית. בכל הפלטפורמות שבדקנו בתעשייה, BuzzPost היחידה ששומרת evidence trail מלא ב־default. אחרים אומרים לך "אל תדאג, אנחנו ניזהר", אבל כשמתחיל הבלאגן — אין לך כלום.

אם אתה רוצה אוטומציה אחראית עם evidence trail מלא — קנה את התוכנית הראשונה ב־249₪ לחודש. עוד מאמרים: אנטי־דטקציה, rate-limit engineering, ניהול חשבונות מרובים.

הערה אחרונה: מי בעל הראיות?

שאלה משפטית שעלתה אצלנו: ה־evidence שנשמרים על VDS של הלקוח, של מי הם? הלקוח? BuzzPost? פייסבוק?

התשובה החוקית: הראיות שייכות לבעל ה־VDS, שזה אתה הלקוח. אנחנו ב־BuzzPost רק מפעילים את ה־VDS עבורך. אם אתה מבקש את כל ה־evidence, אנחנו שולחים לך אותם — הם שלך. אם אתה מסיים לעבוד עם BuzzPost, ה־evidence עוברים אליך לפני שהשרת מתבטל.

זה שונה מ־platform-as-a-service רגיל שבו הדאטה "נעלמת" כשמסתיים השירות. אצלנו: customer ownership of data הוא ערך בסיסי.