login-customer-id
login-customer-id هي ترويسة طلب HTTP في Google Ads API تحمل معرّف العميل لحساب المدير الذي تعمل من خلاله، وتخبر Google أي حساب في الهرم يصرّح بالاستدعاء نيابةً عن الحساب المستهدف.
يستهدف كل طلب إلى Google Ads API معرّف عميل، وهو الحساب الذي تقرأ حملاته أو تعدلها. وعندما يتم الوصول إلى هذا الحساب عبر حساب مدير (MCC)، يحتاج API أيضًا إلى معرفة المسار الذي سلكته للوصول إليه. هذه هي وظيفة login-customer-id: فهو يحدد حساب المدير الذي تمارس تفويضه، ويُرسل من عشرة أرقام دون شرطات (1234567890 وليس 123-456-7890).
القاعدة العامة: إذا كانت بيانات اعتماد OAuth الخاصة بك تعود إلى مستخدم يصل إلى الحساب المستهدف مباشرةً، فيمكنك عادةً حذف الترويسة. أما إذا كان الوصول عبر حساب مدير، وهي الحالة المعتادة للوكالات ولكل من يستخدم رمز مطور صادرًا لـ MCC، فالترويسة مطلوبة. وإغفالها من أكثر أسباب أخطاء USER_PERMISSION_DENIED شيوعًا لدى المطورين الذين يرون الحساب بوضوح في واجهة الويب، لأن الواجهة تجري الحل نفسه بصمت بينما لا يفعل API ذلك.
هناك استخدام ثانٍ أدق. في الهرميات العميقة تحدد الترويسة سياق أي مدير ينطبق، وهذا السياق يؤثر على ما يمكنك رؤيته وفعله: فالميزانيات المشتركة وإجراءات التحويل عبر الحسابات وإعدادات مستوى الحساب تُحل جميعها بالنسبة إلى المدير الذي سجلت الدخول من خلاله. وإرسال MCC خاطئ في بنية متداخلة قد ينتج بيانات جزئية بدلاً من خطأ صريح، وهذا أصعب بكثير في اكتشافه.
هذا بالضبط نوع الأعمال التقنية الخلفية التي يزيلها Opus Growth. ولأننا نشغّل الموصل كخدمة مستضافة، يتم حل سياق المدير نيابةً عنك في كل استدعاء، فتتصل مرة واحدة عبر تسجيل الدخول بحساب Google ولا تتعامل أبدًا مع رمز مطور أو ترويسة معرّف عميل أو حلقة تجديد OAuth بنفسك.
الأسئلة الشائعة
كلما وصلت إلى حساب عبر حساب مدير بدلاً من الوصول المباشر، وهو ما يشمل جميع إعدادات الوكالات تقريبًا وأي تكامل يستخدم رمز مطور صادرًا لـ MCC. أما حسابات الوصول المباشر فيمكنها عادةً حذفه.
الأكثر شيوعًا هو USER_PERMISSION_DENIED، وأحيانًا CUSTOMER_NOT_ENABLED أو خطأ تفويض عام، حتى لو كان المستخدم نفسه يستطيع فتح الحساب بشكل طبيعي في واجهة ويب Google Ads.
عشرة أرقام بعد إزالة الشرطات. الحساب الذي يظهر في الواجهة بصيغة 123-456-7890 يُرسل في الترويسة بصيغة 1234567890.