Business Intelligence

كل ما يعرفه نظام التذاكر لديك، في أربع مجموعات بيانات جاهزة للتحليل.

نحن نعرف التذاكر، وأنت تعرف عملك. تجمع هذه الواجهة الاثنين معًا في مستودع بياناتك ووفق تعريفاتك.

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

صُممت للاستخراج لا للاستعلامات الفردية: تحصل على الصفوف، وتبقى النمذجة والمقاييس والسجل التاريخي ملكك. لا تجميعات ولا تصنيف على جانب الخادم ولا شيء تنتظر منا بناءه. تتحدث OData v4 القياسي، ما يعني أن Power BI وTableau وAzure Data Factory وFivetran تتصل دون كود مخصص.

لفرق البيانات وذكاء الأعمال. إذا كنت تدمج عملية دفع، فأنت تحتاج أحد الوحدات العشر الأخرى.

في لمحة

بيانات حيّةكل طلب يقرأ الحالة الحالية — لا مهمة تصدير ولا لقطة بينهما

تكلفة ترقيم ثابتةيعتمد على keyset، فالصفحة الأخيرة تكلف ما تكلفه الأولى

OData v4تقرأه Power BI وTableau وADF وFivetran دون كود مخصص

500 عمودموزّعة على 4 مجموعات بيانات — التذاكر والمسح والمجموعات الإحصائية والاستبيانات

المخطط من البناءيُولَّد $metadata من النسخة العاملة ولا يمكن أن ينحرف

من آلة إلى آلةبيانات اعتماد عميل OAuth 2.0، بلا CORS، ويبقى سرّك على جانب الخادم

حالات الأعمال

كل سؤال أدناه يجيب عنه فريق بياناتك من الاستخراج، مع قسم المرجع الذي يوضح الطريقة.

كم عدد الأشخاص الذين حضروا فعلًا؟

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

وهو أيضًا الرقم الذي تخطئ فيه معظم التقارير. التذكرة التي لم تُمسح إطلاقًا لا يوجد لها أي صف مسح، فتختفي الفئة التي تريد قياسها في اللحظة التي يكتب فيها أحدهم inner join.

Recipes →

أي شرائح الزوار نمت أو تقلصت مقارنة بالعام السابق؟

حسب المنتج والمجموعة الإحصائية ووثيقة الأهلية وكل حقل تسجيل تطلبه — القطاع والمنصب وحجم الشركة والبلد — عبر دورات العلامة نفسها. ليس كم حضروا، بل من حضر: هذا هو الرقم الذي يصل إلى تقرير مجلس الإدارة.

How ticketing data works → Counting visitors →

أي حملة حققت المبيعات فعلًا؟

كل عملية بيع تحمل معاملات UTM الخاصة بها، فتضع تكلفة كل تذكرة مباعة مقابل كل قناة بدلًا من الاكتفاء بالقول إن الحملة “سارت جيدًا”.

تنبيه يستحق المعرفة قبل بناء لوحة المعلومات: دعوات العارضين لا تحمل أي حملة وتُستخدم بنسبة أقل بكثير. إن أُدرجت في المتوسط، فإنها تخفض كل رقم تحويل تحسبه.

Recipes →

ماذا فعل كل عارض بحصته؟

كم دعوة وزّع، وكم منها استُخدم، ومن استخدمها. هذا أساس زيادة الحصة أو تقليصها أو تسعيرها في العام التالي، وحديث تجريه مع كل عارض على حدة.

Datasets → Tickets →

متى يزدحم كل مدخل؟

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

Datasets → Ticket usages →

ما قيمة الزائر الواحد؟

الإيراد الإجمالي والصافي لكل تذكرة ولكل منتج ولكل قناة ولكل فعالية، مع العملة إلى جانب كل مبلغ، لأن البيانات تحتوي أكثر من عملة واحدة.

Recipes →

ماذا قال لك زوارك، ومن كانوا؟

إجابات الاستبيانات ترتبط بالتذكرة، فكل ما قاله لك الزائر يمكن تقسيمه وفق كل ما تعرفه التذكرة عنه: أي منتج اشترى، ومن أين أتى، وكيف صدرت التذكرة، وأي وثيقة أهلية أبرز.

تتحول الإجابات من إحصاء مجهول إلى شيء يمكنك التصرف بناءً عليه لكل شريحة.

Datasets → Surveys →

الأرقام التي تدخل في التقرير المدقق.

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

How ticketing data works → Counting visitors →

MCP

تجيب الخدمة نفسها عن الأسئلة مباشرة عبر MCP أيضًا، بنفس بيانات الاعتماد ونفس نطاق البيانات، عندما تريد الإجابة لا مجموعة البيانات. اطلب منا صلاحية الوصول.

الوصول

يُمنح الوصول لكل نظام عميل على حدة. تواصل مع جهة اتصالك في ADITUS للحصول على client وsecret، ثم ابدأ من Business Intelligence → Getting started.

كيف يجري الاستخراج نفسه صفحة بعد صفحة: Business Intelligence → Building the extract