كيفية تقييم صنّاع المحتوى على IG من خلال وتيرة النشر: مسار عملي باستخدام Python

من السهل مقارنة صانعَي محتوى على IG استنادًا إلى لقطة واحدة للملف الشخصي؛ لكن الأصعب هو معرفة من ينشر المحتوى بانتظام وأي المنشورات تحصد التفاعلات بمرور الوقت. فالفحوصات المنفردة تخلط بين منشورات متفاوتة العمر، وسرعان ما يصبح الجدول اليدوي قديمًا. والحل العملي هو جمع الوسائط العامة وفق جدول زمني، وحفظ كل استجابة بوصفها ملاحظة مستقلة، واحتساب التغييرات اعتمادًا على بياناتك.

فيما يلي مخطط عمل مناسب لمسوق أو محلل أو مطوّر يحتاج إلى مقارنة الحسابات العامة في مجال واحد أسبوعيًا. تُستخدم واجهة IG Scraper API من jsonscraper للحصول على البيانات، بينما تتولى Python الجدولة والتوحيد وحفظ السجل. وهذا امتداد لموضوع مراقبة الملفات الشخصية والمنشورات المنافسة؛ إذ ينصب التركيز هنا على نموذج موحد للملاحظات يصلح لإعداد تقرير مقارن.

حدّد أولًا ما الذي تريد مقارنته

غالبًا ما تُصاغ المهمة بعبارات واسعة مثل: «العثور على صنّاع محتوى فعّالين». ولجعل المراقبة مفيدة تقنيًا، ينبغي حصرها في أسئلة قابلة للقياس: ما وتيرة نشر المحتوى؟ وما الصيغ المستخدمة؟ وكم عدد الإعجابات والتعليقات العامة الظاهرة وقت الفحص؟ وكيف تتغير هذه الأرقام بعد النشر؟ تساعد هذه المجموعة على اختيار حسابات لدراستها يدويًا أو إعداد ملخص مقارن.

العدادات العامة لقطات تُسجّل وقت الطلب. لذا، فالقرار المعماري الأهم ليس بناء نموذج معقد، بل حفظ وقت الجمع مع القيمة. فإذا جُمعت معلومات الوسيط نفسه كل ليلة ثم استُبدل الصف السابق، ضاع السجل اللازم لحساب النمو. بدلًا من ذلك، احتفظ بالملاحظات على نحو غير قابل للتغيير: صف واحد لكل منشور ووقت جمع.

ينبغي أن تقتصر المقارنة على فترات متماثلة ومنشورات قابلة للمقارنة. فمثلًا، يمكنك النظر إلى المنشورات التي رُصدت للمرة الأولى في شهر تقويمي واحد، أو أخذ عمر المنشور في الحسبان عند كل لقطة. وإلا فسيبدو مقطع نُشر أمس أضعف من منشور أقدم، لمجرد أنه حظي بوقت أقل لتجميع التفاعلات.

مسار العمل: الطلب والتوحيد والسجل

تتكون العملية الأساسية من أربع خطوات: جلب قائمة الوسائط العامة للملفات الشخصية المحددة، وتوحيد الاستجابة وفق مخطط مشترك، وتسجيل الصفوف في مخزن البيانات، وإنشاء تقرير وفق جدول زمني. تعرض صفحة IG Scraper API العنوان الأساسي وخريطة نقاط النهاية، بما في ذلك مسار المستخدم لجلب المنشورات على دفعات. تحقّق من معاملات كل مسار وأمثلة الاستجابة في مجموعة Postman قبل الدمج.

العنوان الأساسي لواجهة API هو https://ig.jsonscraper.com. ولإجراء فحص أولي، تعرض الوثائق طلب الملف الشخصي باسم المستخدم: GET /v1/user/by/username مع المعاملات username وlicense_key وcache_timeout في المثال المنشور. أما جلب المنشورات، فالمسار المحدد له هو GET /v1/user/medias/chunk. خذ المعاملات الدقيقة وحقول متابعة الصفحات وبنية الاستجابة من وثائق هذا الطلب تحديدًا؛ ولا تنقل مخططًا من مسار إلى آخر.

import os
import requests

BASE = "https://ig.jsonscraper.com"
KEY = os.environ["JSONSCRAPER_LICENSE_KEY"]


def get_profile(username: str) -> dict:
    response = requests.get(
        f"{BASE}/v1/user/by/username",
        params={
            "username": username,
            "license_key": KEY,
            "cache_timeout": 60,
        },
        timeout=30,
    )
    response.raise_for_status()
    return response.json()


print(get_profile("example_account"))

يعيد هذا المثال القصير إنتاج مسار الملف الشخصي الموثق، ويوضح تمرير المعاملات عبر HTTP GET. تظهر القيمة cache_timeout=60 في المثال المنشور؛ لذا لا تستخدمها إلا مع المسارات التي تدعم هذا المعامل، وراجع التفاصيل في الوثائق. ويُحفظ المفتاح في متغير بيئة لا في الشيفرة أو تطبيق المتصفح.

أضف جلب المنشورات

بعد التحقق من الملف الشخصي، أضف طلبًا إلى قائمة الوسائط. تذكر صفحة API المسار GET /v1/user/medias/chunk؛ وعند معالجة النتيجة، استخدم آلية تقسيم البيانات إلى دفعات المحددة في الوثائق. خذ أسماء المعاملات وشرط انتهاء ترقيم الصفحات من الوصف الحالي لهذا الطلب في Postman، بدلًا من تخمينها استنادًا إلى اسم المسار.

فيما يلي هيكل أولي لاستدعاء النقل، وليس عقدًا جاهزًا لنقطة النهاية: املأ params بالمعاملات الموثقة قبل التشغيل. وبعد استلام الاستجابة، ينبغي للمحوّل قراءة الحقول التي يؤكدها ملف JSON الفعلي للمسار المختار فقط.

def fetch_media_chunk(username: str, params: dict) -> dict:
    query = {
        **params,
        "username": username,
        "license_key": KEY,
    }
    response = requests.get(
        f"{BASE}/v1/user/medias/chunk",
        params=query,
        timeout=30,
    )
    response.raise_for_status()
    return response.json()

بعد ذلك، اكتب دالة محوّل توحّد الاستجابة وفق صيغة داخلية. وقد تحتاج في التحليل إلى معرّف ثابت للمنشور، واسم المؤلف، والرابط، وتاريخ النشر، ونوع الوسيط، والعدادات العامة المتاحة. تحقّق من الأسماء والأنواع الدقيقة للحقول بمراجعة الوثائق ومثال JSON. وإذا غاب مقياس ما، فاحفظه كقيمة فارغة بدلًا من وضع صفر؛ فالصفر يعني أن العداد قيس وكانت قيمته صفرًا، أما القيمة الفارغة فتعني غياب البيانات.

def normalize_media(item: dict, username: str, observed_at: str) -> dict:
    # حدّد المفاتيح بعد التحقق من JSON لنقطة النهاية المختارة.
    return {
        "username": username,
        "media_id": item.get("DOCUMENTED_MEDIA_ID_KEY"),
        "media_url": item.get("DOCUMENTED_MEDIA_URL_KEY"),
        "published_at": item.get("DOCUMENTED_PUBLISHED_AT_KEY"),
        "media_type": item.get("DOCUMENTED_MEDIA_TYPE_KEY"),
        "likes": item.get("DOCUMENTED_LIKE_COUNT_KEY"),
        "comments": item.get("DOCUMENTED_COMMENT_COUNT_KEY"),
        "observed_at": observed_at,
    }

استبدل الأسماء النائبة بالمفاتيح الدقيقة من استجابة نقطة النهاية المحددة، وثبّت عملية الربط باختبار يستخدم عينة JSON محفوظة. وهكذا يصبح أي تغيير في المخطط ملحوظًا عند تحديث الدمج، ولا يوحي المثال بأن أسماء الحقول المفترضة عقد موثّق.

احتفظ بالملاحظات، لا بالقيم الحالية وحدها

يكفي CSV لإعداد نموذج أولي؛ أما العمل المنتظم فيناسبه PostgreSQL أو Supabase أو مستودع تحليلي. يمكن أن يحتوي جدول الملاحظات على الحقول username وmedia_id وpublished_at وobserved_at وlikes وcomments وملف JSON الخام. ويحدد الجمع بين media_id وobserved_at لقطة فريدة. أما جدول الملفات الشخصية المنفصل فيحفظ قائمة الحسابات المتعقبة وتاريخ إضافتها إلى المراقبة.

يفيد حفظ الاستجابة الخام في تصحيح الأخطاء وإعادة إنشاء البيانات الموحدة. حدّد مدة الاحتفاظ بالبيانات بما يتوافق مع غرض المشروع وقواعد المؤسسة، وتحكّم في الوصول إلى الجداول، ولا تجمع معلومات لا تحتاج إليها للتحليل المختار. أما استخدام البيانات في أنظمة إدارة علاقات العملاء أو أنشطة التسويق المباشر، فيتطلب تحديد الأساس القانوني المنطبق بصورة مستقلة؛ فالإتاحة التقنية للبيانات العامة لا تحسم هذه المسألة.

CREATE TABLE media_observations (
    username TEXT NOT NULL,
    media_id TEXT NOT NULL,
    media_url TEXT,
    published_at TIMESTAMPTZ,
    observed_at TIMESTAMPTZ NOT NULL,
    media_type TEXT,
    likes BIGINT,
    comments BIGINT,
    raw_json JSONB,
    PRIMARY KEY (media_id, observed_at)
);

أضف السجلات على دفعات بعد نجاح التحقق من الاستجابة. وعند إعادة تشغيل المهمة نفسها، يمنع الجمع بين حقلي المفتاح الأساسي إنشاء لقطة مكررة عن طريق الخطأ؛ ويمكن للتطبيق استخدام إدراج يتجاوز التعارض. أما التشغيل في وقت مختلف، فيحفظ صفًا مستقلًا ويواصل السلسلة الزمنية.

احسب المقاييس التي تجيب عن السؤال

المقياس الأساسي لوتيرة النشر هو عدد الوسائط الفريدة للحساب خلال فترة محددة. ويمكن حسابه بسهولة باستخدام published_at إذا كان الحقل موجودًا وتعرّف عليه النظام على نحو صحيح. ولتقدير تغير التفاعلات العامة، قارن ملاحظتين للعنصر نفسه media_id: يساوي التغير المطلق في الإعجابات العداد اللاحق ناقص العداد السابق، أما التغير النسبي فهو التغير مقسومًا على القيمة السابقة. وينطبق الحساب نفسه على التعليقات.

إذا كانت القيمة السابقة صفرًا أو غير متاحة، فلا يمكن تحديد نسبة النمو؛ اعرض الفرق المطلق ووضّح صراحةً عدم وجود قيمة أساس لحساب النسبة. قد تتغير العدادات بين الملاحظات، لذا ينبغي أن يبيّن التقرير الفاصل الزمني بين اللقطات ووقت آخر عملية جمع. وتساعد هذه التفاصيل القارئ على تفسير الأرقام تفسيرًا سليمًا.

def growth(previous, current):
    if previous is None or current is None:
        return {"delta": None, "rate": None}
    delta = current - previous
    rate = None if previous == 0 else delta / previous
    return {"delta": delta, "rate": rate}

لا تختزل الحسابات في ترتيب واحد من دون أوزان قابلة للتفسير. يعرض التقرير العملي عادةً عدد المنشورات، ووسيط الإعجابات والتعليقات لكل منشور، وتوزيع الصيغ، وتغير التفاعلات ضمن فترات عمرية متماثلة. ويحدّ الوسيط من تأثير المنشور الشاذ، فيما يوضح عدد المنشورات حجم العينة التي تستند إليها المقارنة.

يمكن أخذ عمر المنشور في الحسبان بطريقتين. الأولى هي تسجيل العدادات دوريًا، مثلًا على فترات متساوية بعد اكتشاف الوسيط للمرة الأولى. والثانية هي مقارنة المنشورات التي ظهرت ضمن نطاق زمني واحد، باستخدام ملاحظات متقاربة في العمر. وإذا فات أحد مواعيد التشغيل، فلا تصف التغير الفعلي بأنه زيادة دقيقة خلال يوم؛ بل احسب الفاصل اعتمادًا على الطوابع الزمنية.

أتمت الجدولة ومراقبة الجودة

شغّل عملية الجمع وفق جدول زمني باستخدام cron أو GitHub Actions أو منسّق ETL. وتسلسل المهمة بسيط: قراءة قائمة الحسابات، وطلب الدفعات اللازمة، والتحقق من حالة HTTP وبنية الاستجابة، وتوحيد البيانات، وحفظ اللقطة، وتسجيل تنفيذ المهمة. وثبّت في كل تشغيل عدد الحسابات والوسائط المعالجة، والأخطاء، والمدة؛ فهذا يساعد على التمييز بين تغير النشاط الفعلي وتعطل عملية الجمع.

استخدم عددًا محدودًا من المحاولات مع فاصل انتظار عند وقوع أخطاء مؤقتة، واحفظ سياق الطلب عند فشل الاستجابة من دون مفتاح سري. ولا تشغّل حلقة لا نهائية لاجتياز المؤشرات؛ يجب أن يتوقف التنفيذ وفق شروط الإنهاء المحددة في استجابة نقطة النهاية. وإذا وضعت الوثائق حدودًا أو قواعد للاستخدام، فاضبط وتيرة الجمع وحجم العينة بما يتوافق معها.

يُذكر المعامل cache_timeout في صفحة IG API للمسارات التي تدعمه. ويفيد التخزين المؤقت عندما لا يضيف تكرار الطلب خلال فترة قصيرة قيمة جديدة؛ لذا اختر فاصل الجمع بما يتناسب مع السؤال التحليلي. فمثلًا، تكون اللقطة اليومية أنسب لمراجعة أسبوعية من تكرار الطلبات مرارًا إلى الملفات الشخصية نفسها بلا غرض محدد.

اختبر عينة صغيرة قبل تفعيل الجدولة المنتظمة. احفظ نموذجًا للاستجابة، وتحقق من المعرّفات والتواريخ، وقارن الحقول الموحّدة بملف JSON الأصلي، وافحص يدويًا عدة صفوف. أضف اختبارات للقيم الغائبة والقوائم الفارغة والتنسيقات غير المتوقعة. وعند تغير API، تكشف هذه الفحوصات المشكلة أسرع من تقرير غير متسق في نهاية الأسبوع.

ما فائدة الذكاء الاصطناعي هنا؟

يكون الذكاء الاصطناعي مناسبًا في المرحلة الأخيرة، لتلخيص النتائج المحسوبة بالفعل. زوّد النموذج بالمجاميع وروابط المنشورات، لا بالأرشيف الخام كله؛ مثلًا عدد الوسائط أسبوعيًا، ووسيط التفاعلات العامة، وقائمة المنشورات التي شهدت أكبر تغير خلال فترة محددة. واطلب من النموذج صياغة ملاحظات وإرفاق معرّفات السجلات التي استند إليها.

الأفضل ترك حساب المقاييس للشيفرة العادية كي تعطي القاعدة نفسها نتائج قابلة لإعادة الإنتاج. ويمكن للنموذج إعداد ملخص نصي، أو تصنيف التعليقات وفق موضوعات محددة مسبقًا، أو اقتراح أسئلة للمراجعة اليدوية. وعند تصنيف الموضوعات، احفظ تصنيف النموذج منفصلًا عن التعليق الأصلي، وسجّل إصدار التعليمات أو المصنّف كي لا تؤدي التغييرات اللاحقة إلى إعادة كتابة السجل من دون ملاحظة.

لا تحوّل التقرير الآلي إلى قرار آلي بشأن توظيف شخص بعينه أو التعاقد معه أو تقييمه. استخدم البيانات العامة لتحليل محدود للمحتوى، وتحقق يدويًا من الاستنتاجات، ولا سيما عندما تؤثر في قرارات العمل. وبهذا تحافظ على فائدة المراقبة، وتفصل بين العدادات القابلة للقياس وتفسيرها.

ما شكل النتيجة؟

بعد دورات جمع متعددة، سيظهر جدول يبيّن وقت اكتشاف كل منشور، وعدد التفاعلات المسجلة في كل ملاحظة، وكيف تغيرت المؤشرات. وسيتمكن الملخص الأسبوعي من الإجابة عن أسئلة عملية: من نشر بانتظام؟ وما الصيغ الأكثر استخدامًا؟ وأي المنشورات اكتسبت تفاعلات بين لقطات قابلة للمقارنة؟ وأين لا تزال البيانات غير كافية لإجراء مقارنة موثوقة؟

تساعد هذه العملية على استبدال الفحوصات اليدوية المتقطعة بدراسة قابلة للتكرار. لكنها لا تغني عن التحليل النوعي للمحتوى: فالمقاييس تصف وتيرة النشر والتفاعلات العامة المتاحة، أما المعنى والجمهور ومدى ملاءمة المحتوى للعلامة التجارية فتتطلب تقييمًا مستقلًا. ومع ذلك، تجعل الجدولة الموحدة والسجل المحفوظ ومنطق الحساب الواضح هذه التقييمات قابلة للتحقق ومفيدة للفريق.

للبدء، افتح صفحة IG Scraper API، وتحقق من معاملات مسار المنشورات في وثائق Postman، ثم نفّذ المحوّل على حساب تجريبي واحفظ اللقطة الأولى. وبعد التحقق من المخطط، أضف الجدولة ومراقبة الأخطاء والتقرير المستند إلى المقاييس المختارة.