ഓൺലൈൻ സൈറ്റുകളിൽ നിന്ന് പരസ്യ കാമ്പെയ്‌നുകളെക്കുറിച്ചുള്ള ഡാറ്റ ഞങ്ങൾ എങ്ങനെയാണ് ശേഖരിച്ചത് (ഉൽപ്പന്നത്തിലേക്കുള്ള മുള്ളുള്ള പാത)

ഓൺലൈൻ പരസ്യം ചെയ്യൽ മേഖല കഴിയുന്നത്ര സാങ്കേതികമായി പുരോഗമിച്ചതും യാന്ത്രികവുമായിരിക്കണം എന്ന് തോന്നുന്നു. തീർച്ചയായും, Yandex, Mail.Ru, Google, Facebook പോലുള്ള അവരുടെ മേഖലയിലെ ഭീമന്മാരും വിദഗ്ധരും അവിടെ പ്രവർത്തിക്കുന്നു. പക്ഷേ, അത് മാറിയതുപോലെ, പൂർണ്ണതയ്ക്ക് പരിധിയില്ല, എല്ലായ്പ്പോഴും യാന്ത്രികമാക്കാൻ എന്തെങ്കിലും ഉണ്ട്.

ഉറവിടം

ആശയവിനിമയ ഗ്രൂപ്പ് ഡെൻ്റ്സു ഏജിസ് നെറ്റ്‌വർക്ക് റഷ്യ ഡിജിറ്റൽ പരസ്യ വിപണിയിലെ ഏറ്റവും വലിയ കളിക്കാരനാണ്, സാങ്കേതികവിദ്യയിൽ സജീവമായി നിക്ഷേപം നടത്തുന്നു, അതിൻ്റെ ബിസിനസ്സ് പ്രക്രിയകൾ ഒപ്റ്റിമൈസ് ചെയ്യാനും ഓട്ടോമേറ്റ് ചെയ്യാനും ശ്രമിക്കുന്നു. വിവിധ ഇൻ്റർനെറ്റ് പ്ലാറ്റ്‌ഫോമുകളിൽ നിന്നുള്ള പരസ്യ കാമ്പെയ്‌നുകളുടെ സ്ഥിതിവിവരക്കണക്കുകൾ ശേഖരിക്കുക എന്നതാണ് ഓൺലൈൻ പരസ്യ വിപണിയുടെ പരിഹരിക്കപ്പെടാത്ത പ്രശ്‌നങ്ങളിലൊന്ന്. ഈ പ്രശ്നത്തിനുള്ള പരിഹാരം ആത്യന്തികമായി ഒരു ഉൽപ്പന്നത്തിൻ്റെ സൃഷ്ടിയിൽ കലാശിച്ചു ഡി 1. ഡിജിറ്റൽ (ദിവാൻ എന്ന് വായിക്കുക), ഞങ്ങൾ സംസാരിക്കാൻ ആഗ്രഹിക്കുന്ന വികസനം.

എന്തുകൊണ്ട്?

1. പ്രോജക്റ്റ് ആരംഭിക്കുന്ന സമയത്ത്, പരസ്യ കാമ്പെയ്‌നുകളിലെ സ്ഥിതിവിവരക്കണക്കുകളുടെ ശേഖരണം ഓട്ടോമേറ്റ് ചെയ്യുന്നതിനുള്ള പ്രശ്നം പരിഹരിച്ച ഒരു റെഡിമെയ്ഡ് ഉൽപ്പന്നം പോലും വിപണിയിൽ ഉണ്ടായിരുന്നില്ല. നമ്മളല്ലാതെ മറ്റാരും നമ്മുടെ ആവശ്യങ്ങൾ നിറവേറ്റില്ല എന്നാണ് ഇതിനർത്ഥം.

Improvado, Roistat, Supermetrics, SegmentStream തുടങ്ങിയ സേവനങ്ങൾ പ്ലാറ്റ്‌ഫോമുകൾ, സോഷ്യൽ നെറ്റ്‌വർക്കുകൾ, Google Analytics എന്നിവയുമായി സംയോജനം വാഗ്ദാനം ചെയ്യുന്നു, കൂടാതെ സൗകര്യപ്രദമായ വിശകലനത്തിനും പരസ്യ കാമ്പെയ്‌നുകളുടെ നിയന്ത്രണത്തിനും അനലിറ്റിക്കൽ ഡാഷ്‌ബോർഡുകൾ നിർമ്മിക്കുന്നത് സാധ്യമാക്കുന്നു. ഞങ്ങളുടെ ഉൽപ്പന്നം വികസിപ്പിക്കാൻ തുടങ്ങുന്നതിനുമുമ്പ്, സൈറ്റുകളിൽ നിന്ന് ഡാറ്റ ശേഖരിക്കാൻ ഈ സിസ്റ്റങ്ങളിൽ ചിലത് ഉപയോഗിക്കാൻ ഞങ്ങൾ ശ്രമിച്ചു, പക്ഷേ, നിർഭാഗ്യവശാൽ, അവർക്ക് ഞങ്ങളുടെ പ്രശ്നങ്ങൾ പരിഹരിക്കാനായില്ല.

പരീക്ഷിച്ച ഉൽപ്പന്നങ്ങൾ ഡാറ്റ സ്രോതസ്സുകളെ ആശ്രയിച്ചിരിക്കുന്നു, സൈറ്റ് പ്രകാരം പ്ലേസ്മെൻ്റ് സ്ഥിതിവിവരക്കണക്കുകൾ പ്രദർശിപ്പിക്കുന്നു, കൂടാതെ പരസ്യ കാമ്പെയ്‌നുകളിലെ സ്ഥിതിവിവരക്കണക്കുകൾ സമാഹരിക്കാനുള്ള കഴിവ് നൽകിയില്ല എന്നതാണ് പ്രധാന പ്രശ്നം. വ്യത്യസ്ത സൈറ്റുകളിൽ നിന്നുള്ള സ്ഥിതിവിവരക്കണക്കുകൾ ഒരിടത്ത് കാണാനും പ്രചാരണത്തിൻ്റെ മൊത്തത്തിലുള്ള അവസ്ഥ വിശകലനം ചെയ്യാനും ഈ സമീപനം ഞങ്ങളെ അനുവദിച്ചില്ല.

മറ്റൊരു ഘടകം, പ്രാരംഭ ഘട്ടങ്ങളിൽ ഉൽപ്പന്നങ്ങൾ പാശ്ചാത്യ വിപണിയെ ലക്ഷ്യം വച്ചുള്ളതായിരുന്നു, റഷ്യൻ സൈറ്റുകളുമായുള്ള സംയോജനത്തെ പിന്തുണച്ചില്ല. സംയോജനം നടപ്പിലാക്കിയ സൈറ്റുകൾക്കായി, ആവശ്യമായ എല്ലാ അളവുകളും എല്ലായ്‌പ്പോഴും മതിയായ വിശദാംശങ്ങളോടെ ഡൗൺലോഡ് ചെയ്‌തിട്ടില്ല, മാത്രമല്ല സംയോജനം എല്ലായ്പ്പോഴും സൗകര്യപ്രദവും സുതാര്യവുമല്ല, പ്രത്യേകിച്ചും സിസ്റ്റം ഇൻ്റർഫേസിൽ ഇല്ലാത്ത എന്തെങ്കിലും ലഭിക്കാൻ ആവശ്യമായി വരുമ്പോൾ.
പൊതുവേ, മൂന്നാം കക്ഷി ഉൽപ്പന്നങ്ങളുമായി പൊരുത്തപ്പെടേണ്ടെന്ന് ഞങ്ങൾ തീരുമാനിച്ചു, പക്ഷേ സ്വന്തമായി വികസിപ്പിക്കാൻ തുടങ്ങി...

2. ഓൺലൈൻ പരസ്യ വിപണി വർഷം തോറും വളരുകയാണ്, 2018-ൽ, പരസ്യ ബജറ്റുകളുടെ കാര്യത്തിൽ, പരമ്പരാഗതമായി ഏറ്റവും വലിയ ടിവി പരസ്യ വിപണിയെ അത് മറികടന്നു. അതിനാൽ ഒരു സ്കെയിലുണ്ട്.

3. ടിവി പരസ്യ വിപണിയിൽ നിന്ന് വ്യത്യസ്തമായി, വാണിജ്യ പരസ്യങ്ങളുടെ വിൽപന കുത്തകയാണ്, സ്വന്തം പരസ്യ അക്കൗണ്ടുകൾ ഉപയോഗിച്ച് ഇൻ്റർനെറ്റിൽ പ്രവർത്തിക്കുന്ന വിവിധ വലുപ്പത്തിലുള്ള പരസ്യ ഇൻവെൻ്ററിയുടെ വ്യക്തിഗത ഉടമകൾ ധാരാളം ഉണ്ട്. ഒരു പരസ്യ കാമ്പെയ്ൻ, ചട്ടം പോലെ, ഒരേസമയം നിരവധി സൈറ്റുകളിൽ പ്രവർത്തിക്കുന്നതിനാൽ, പരസ്യ കാമ്പെയ്‌നിൻ്റെ അവസ്ഥ മനസിലാക്കാൻ, എല്ലാ സൈറ്റുകളിൽ നിന്നും റിപ്പോർട്ടുകൾ ശേഖരിക്കുകയും അവയെ ഒരു വലിയ റിപ്പോർട്ടായി സംയോജിപ്പിക്കുകയും ചെയ്യേണ്ടത് ആവശ്യമാണ്, അത് മുഴുവൻ ചിത്രവും കാണിക്കും. ഇതിനർത്ഥം ഒപ്റ്റിമൈസേഷന് സാധ്യതയുണ്ടെന്നാണ്.

4. ഇൻറർനെറ്റിലെ പരസ്യ ഇൻവെൻ്ററി ഉടമകൾക്ക് സ്ഥിതിവിവരക്കണക്കുകൾ ശേഖരിക്കുന്നതിനും അവ പരസ്യ അക്കൗണ്ടുകളിൽ പ്രദർശിപ്പിക്കുന്നതിനുമുള്ള ഇൻഫ്രാസ്ട്രക്ചർ ഇതിനകം ഉണ്ടെന്ന് ഞങ്ങൾക്ക് തോന്നി, കൂടാതെ അവർക്ക് ഈ ഡാറ്റയ്‌ക്കായി ഒരു API നൽകാൻ കഴിയും. സാങ്കേതികമായി ഇത് നടപ്പിലാക്കാൻ കഴിയുമെന്നാണ് ഇതിനർത്ഥം. അത് അത്ര ലളിതമല്ലെന്ന് ഇപ്പോൾ തന്നെ പറയാം.

പൊതുവേ, പ്രോജക്റ്റ് നടപ്പിലാക്കുന്നതിനുള്ള എല്ലാ മുൻവ്യവസ്ഥകളും ഞങ്ങൾക്ക് വ്യക്തമായിരുന്നു, കൂടാതെ പ്രോജക്റ്റ് ജീവസുറ്റതാക്കാൻ ഞങ്ങൾ ഓടി ...

ഗ്രാൻഡ് പ്ലാൻ

തുടക്കത്തിൽ, ഞങ്ങൾ ഒരു അനുയോജ്യമായ സംവിധാനത്തിൻ്റെ ഒരു ദർശനം രൂപീകരിച്ചു:

• 1C കോർപ്പറേറ്റ് സിസ്റ്റത്തിൽ നിന്നുള്ള പരസ്യ കാമ്പെയ്‌നുകൾ അവയുടെ പേരുകൾ, കാലയളവുകൾ, ബജറ്റുകൾ, വിവിധ പ്ലാറ്റ്‌ഫോമുകളിലെ പ്ലെയ്‌സ്‌മെൻ്റുകൾ എന്നിവയ്‌ക്കൊപ്പം സ്വയമേവ അതിൽ ലോഡ് ചെയ്യണം.
• ഒരു പരസ്യ കാമ്പെയ്‌നിലെ ഓരോ പ്ലേസ്‌മെൻ്റിനും, സാധ്യമായ എല്ലാ സ്ഥിതിവിവരക്കണക്കുകളും പ്ലേസ്‌മെൻ്റ് നടക്കുന്ന സൈറ്റുകളിൽ നിന്ന് സ്വയമേവ ഡൗൺലോഡ് ചെയ്യണം, ഇംപ്രഷനുകളുടെ എണ്ണം, ക്ലിക്കുകൾ, കാഴ്ചകൾ മുതലായവ.
• Adriver, Weborama, DCM മുതലായ പരസ്യ സംവിധാനങ്ങൾ എന്ന് വിളിക്കപ്പെടുന്ന മൂന്നാം കക്ഷി നിരീക്ഷണം ഉപയോഗിച്ച് ചില പരസ്യ പ്രചാരണങ്ങൾ ട്രാക്ക് ചെയ്യപ്പെടുന്നു. റഷ്യയിൽ ഒരു വ്യാവസായിക ഇൻ്റർനെറ്റ് മീറ്ററും ഉണ്ട് - മീഡിയസ്കോപ്പ് കമ്പനി. ഞങ്ങളുടെ പ്ലാൻ അനുസരിച്ച്, സ്വതന്ത്രവും വ്യാവസായികവുമായ നിരീക്ഷണത്തിൽ നിന്നുള്ള ഡാറ്റയും അനുബന്ധ പരസ്യ കാമ്പെയ്‌നുകളിലേക്ക് സ്വയമേവ ലോഡ് ചെയ്യണം.
• ഇൻറർനെറ്റിലെ മിക്ക പരസ്യ കാമ്പെയ്‌നുകളും ലക്ഷ്യം വച്ചുള്ള ചില ടാർഗെറ്റ് പ്രവർത്തനങ്ങൾ (വാങ്ങുക, വിളിക്കുക, ഒരു ടെസ്റ്റ് ഡ്രൈവിനായി സൈൻ അപ്പ് ചെയ്യുക മുതലായവ) ലക്ഷ്യമിടുന്നു, അവ Google Analytics ഉപയോഗിച്ച് ട്രാക്ക് ചെയ്യപ്പെടുന്നു, കൂടാതെ കാമ്പെയ്‌നിൻ്റെ നില മനസ്സിലാക്കുന്നതിന് പ്രധാനമായ സ്ഥിതിവിവരക്കണക്കുകളും ഞങ്ങളുടെ ടൂളിലേക്ക് ലോഡ് ചെയ്യണം.

ആദ്യത്തെ പാൻകേക്ക് മെഴുകുതിരിയാണ്

സോഫ്റ്റ്‌വെയർ വികസനത്തിൻ്റെ വഴക്കമുള്ള തത്വങ്ങളോടുള്ള ഞങ്ങളുടെ പ്രതിബദ്ധത കണക്കിലെടുത്ത് (ചുരുക്കമുള്ളത്, എല്ലാം), ഞങ്ങൾ ആദ്യം ഒരു MVP വികസിപ്പിക്കാനും തുടർന്ന് ഉദ്ദേശിച്ച ലക്ഷ്യത്തിലേക്ക് ആവർത്തിച്ച് നീങ്ങാനും തീരുമാനിച്ചു.
ഞങ്ങളുടെ ഉൽപ്പന്നത്തെ അടിസ്ഥാനമാക്കി MVP നിർമ്മിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു DANBo (Dentsu Aegis നെറ്റ്‌വർക്ക് ബോർഡ്), ഇത് ഞങ്ങളുടെ ക്ലയൻ്റുകളുടെ പരസ്യ കാമ്പെയ്‌നുകളെക്കുറിച്ചുള്ള പൊതുവായ വിവരങ്ങളുള്ള ഒരു വെബ് ആപ്ലിക്കേഷനാണ്.

എംവിപിയെ സംബന്ധിച്ചിടത്തോളം, പദ്ധതി നടപ്പാക്കലിൻ്റെ കാര്യത്തിൽ കഴിയുന്നത്ര ലളിതമാക്കി. സംയോജനത്തിനായി പ്ലാറ്റ്‌ഫോമുകളുടെ പരിമിതമായ ലിസ്റ്റ് ഞങ്ങൾ തിരഞ്ഞെടുത്തു. Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB, കൂടാതെ പ്രധാന പരസ്യ സംവിധാനങ്ങളായ Adriver, Weborama എന്നിവയും ഇവയായിരുന്നു പ്രധാന പ്ലാറ്റ്‌ഫോമുകൾ.

API വഴി സൈറ്റുകളിലെ സ്ഥിതിവിവരക്കണക്കുകൾ ആക്സസ് ചെയ്യാൻ, ഞങ്ങൾ ഒരൊറ്റ അക്കൗണ്ട് ഉപയോഗിച്ചു. ഒരു പരസ്യ കാമ്പെയ്‌നിൽ സ്ഥിതിവിവരക്കണക്കുകളുടെ യാന്ത്രിക ശേഖരണം ഉപയോഗിക്കാൻ ആഗ്രഹിക്കുന്ന ഒരു ക്ലയൻ്റ് ഗ്രൂപ്പ് മാനേജർ ആദ്യം പ്ലാറ്റ്‌ഫോം അക്കൗണ്ടിലേക്ക് സൈറ്റുകളിലെ ആവശ്യമായ പരസ്യ കാമ്പെയ്‌നുകളിലേക്കുള്ള ആക്‌സസ് ഡെലിഗേറ്റ് ചെയ്യേണ്ടതുണ്ട്.

അടുത്തത് സിസ്റ്റം ഉപയോക്താവാണ് DANBo എക്സൽ സിസ്റ്റത്തിലേക്ക് ഒരു പ്രത്യേക ഫോർമാറ്റിൻ്റെ ഫയൽ അപ്‌ലോഡ് ചെയ്യേണ്ടതുണ്ട്, അതിൽ പ്ലേസ്‌മെൻ്റ് (പരസ്യ കാമ്പെയ്ൻ, പ്ലാറ്റ്‌ഫോം, ഫോർമാറ്റ്, പ്ലേസ്‌മെൻ്റ് കാലയളവ്, ആസൂത്രിത സൂചകങ്ങൾ, ബജറ്റ് മുതലായവ) അനുബന്ധ പരസ്യ കാമ്പെയ്‌നുകളുടെ ഐഡൻ്റിഫയറുകൾ എന്നിവയെക്കുറിച്ചുള്ള എല്ലാ വിവരങ്ങളും അടങ്ങിയിരിക്കുന്നു. പരസ്യ സംവിധാനങ്ങളിലെ സൈറ്റുകളും കൗണ്ടറുകളും.

ഇത് വ്യക്തമായി, ഭയപ്പെടുത്തുന്നതായി കാണപ്പെട്ടു:

ഡൗൺലോഡ് ചെയ്‌ത ഡാറ്റ ഒരു ഡാറ്റാബേസിലേക്ക് സംരക്ഷിച്ചു, തുടർന്ന് പ്രത്യേക സേവനങ്ങൾ അവയിൽ നിന്ന് സൈറ്റുകളിലെ പ്രചാരണ ഐഡൻ്റിഫയറുകൾ ശേഖരിക്കുകയും അവയിലെ സ്ഥിതിവിവരക്കണക്കുകൾ ഡൗൺലോഡ് ചെയ്യുകയും ചെയ്തു.

ഓരോ സൈറ്റിനും, ഒരു പ്രത്യേക വിൻഡോസ് സേവനം എഴുതിയിട്ടുണ്ട്, അത് സൈറ്റിൻ്റെ API-യിലെ ഒരു സേവന അക്കൗണ്ടിന് കീഴിൽ ദിവസത്തിൽ ഒരിക്കൽ പോകുകയും നിർദ്ദിഷ്‌ട പ്രചാരണ ഐഡികൾക്കായുള്ള സ്ഥിതിവിവരക്കണക്കുകൾ ഡൗൺലോഡ് ചെയ്യുകയും ചെയ്തു. പരസ്യ സംവിധാനങ്ങളിലും ഇതുതന്നെ സംഭവിച്ചു.

ഡൗൺലോഡ് ചെയ്‌ത ഡാറ്റ ഒരു ചെറിയ ഇഷ്‌ടാനുസൃത ഡാഷ്‌ബോർഡിൻ്റെ രൂപത്തിൽ ഇൻ്റർഫേസിൽ പ്രദർശിപ്പിച്ചു:

ഞങ്ങൾക്ക് അപ്രതീക്ഷിതമായി, MVP പ്രവർത്തിക്കാൻ തുടങ്ങി, ഇൻ്റർനെറ്റിലെ പരസ്യ കാമ്പെയ്‌നുകളെക്കുറിച്ചുള്ള നിലവിലെ സ്ഥിതിവിവരക്കണക്കുകൾ ഡൗൺലോഡ് ചെയ്യാൻ തുടങ്ങി. ഞങ്ങൾ നിരവധി ക്ലയൻ്റുകളിൽ സിസ്റ്റം നടപ്പിലാക്കി, എന്നാൽ സ്കെയിൽ ചെയ്യാൻ ശ്രമിക്കുമ്പോൾ, ഞങ്ങൾ ഗുരുതരമായ പ്രശ്നങ്ങൾ നേരിട്ടു:

• സിസ്റ്റത്തിലേക്ക് ലോഡുചെയ്യുന്നതിനുള്ള ഡാറ്റ തയ്യാറാക്കുന്നതിൻ്റെ സങ്കീർണ്ണതയായിരുന്നു പ്രധാന പ്രശ്നം. കൂടാതെ, ലോഡുചെയ്യുന്നതിന് മുമ്പ് പ്ലേസ്‌മെൻ്റ് ഡാറ്റ കർശനമായി നിശ്ചിത ഫോർമാറ്റിലേക്ക് പരിവർത്തനം ചെയ്യേണ്ടതുണ്ട്. ഡൗൺലോഡ് ഫയലിൽ വ്യത്യസ്ത സൈറ്റുകളിൽ നിന്നുള്ള എൻ്റിറ്റി ഐഡൻ്റിഫയറുകൾ ഉൾപ്പെടുത്തേണ്ടത് ആവശ്യമാണ്. സൈറ്റിൽ ഈ ഐഡൻ്റിഫയറുകൾ എവിടെ കണ്ടെത്താമെന്നും ഫയലിൽ എവിടെയാണ് അവ നൽകേണ്ടതെന്നും വിശദീകരിക്കാൻ സാങ്കേതികമായി പരിശീലനം ലഭിക്കാത്ത ഉപയോക്താക്കൾക്ക് വളരെ ബുദ്ധിമുട്ടാണ് എന്ന വസ്തുത ഞങ്ങൾ അഭിമുഖീകരിക്കുന്നു. സൈറ്റുകളിൽ കാമ്പെയ്‌നുകൾ നടത്തുന്ന ഡിപ്പാർട്ട്‌മെൻ്റുകളിലെ ജീവനക്കാരുടെ എണ്ണവും വിറ്റുവരവും കണക്കിലെടുക്കുമ്പോൾ, ഇത് ഞങ്ങളുടെ ഭാഗത്ത് വലിയൊരു പിന്തുണക്ക് കാരണമായി, ഞങ്ങൾ തീർത്തും തൃപ്തരായിരുന്നില്ല.
• എല്ലാ പരസ്യ പ്ലാറ്റ്‌ഫോമുകളിലും മറ്റ് അക്കൗണ്ടുകളിലേക്ക് പരസ്യ കാമ്പെയ്‌നുകളിലേക്കുള്ള ആക്‌സസ് ഡെലിഗേറ്റ് ചെയ്യുന്നതിനുള്ള സംവിധാനം ഇല്ലെന്നതാണ് മറ്റൊരു പ്രശ്‌നം. എന്നാൽ ഒരു ഡെലിഗേഷൻ സംവിധാനം ലഭ്യമാണെങ്കിലും, എല്ലാ പരസ്യദാതാക്കളും മൂന്നാം കക്ഷി അക്കൗണ്ടുകളിലേക്ക് അവരുടെ കാമ്പെയ്‌നുകളിലേക്ക് ആക്‌സസ് അനുവദിക്കാൻ തയ്യാറായില്ല.
• ഞങ്ങളുടെ 1C അക്കൗണ്ടിംഗ് സിസ്റ്റത്തിലേക്ക് അവർ ഇതിനകം നൽകിയിട്ടുള്ള എല്ലാ ആസൂത്രിത സൂചകങ്ങളും പ്ലെയ്‌സ്‌മെൻ്റ് വിശദാംശങ്ങളും അവർ വീണ്ടും പ്രവേശിക്കണം എന്ന വസ്തുത ഉപയോക്താക്കൾക്കിടയിൽ ഉണർത്തിയ രോഷമാണ് ഒരു പ്രധാന ഘടകം. DANBo.

പ്ലെയ്‌സ്‌മെൻ്റിനെക്കുറിച്ചുള്ള വിവരങ്ങളുടെ പ്രാഥമിക ഉറവിടം ഞങ്ങളുടെ 1C സിസ്റ്റമായിരിക്കണം എന്ന ആശയം ഇത് ഞങ്ങൾക്ക് നൽകി, അതിൽ എല്ലാ ഡാറ്റയും കൃത്യസമയത്തും കൃത്യസമയത്തും നൽകപ്പെടുന്നു (1C ഡാറ്റയെ അടിസ്ഥാനമാക്കിയാണ് ഇൻവോയ്‌സുകൾ ജനറേറ്റുചെയ്യുന്നത്, അതിനാൽ 1C-യിലേക്ക് ഡാറ്റ ശരിയായി എൻട്രി ചെയ്യുക എന്നതാണ്. എല്ലാവരുടെയും മുൻഗണന KPI). ഇങ്ങനെയാണ് സിസ്റ്റത്തിൻ്റെ ഒരു പുതിയ ആശയം ഉടലെടുത്തത്.

ആശയം

ഇൻ്റർനെറ്റിലെ പരസ്യ കാമ്പെയ്‌നുകളെക്കുറിച്ചുള്ള സ്ഥിതിവിവരക്കണക്കുകൾ ശേഖരിക്കുന്നതിനുള്ള സംവിധാനത്തെ ഒരു പ്രത്യേക ഉൽപ്പന്നമായി വേർതിരിക്കുക എന്നതാണ് ഞങ്ങൾ ആദ്യം തീരുമാനിച്ചത് - ഡി 1. ഡിജിറ്റൽ.

പുതിയ ആശയത്തിൽ, ഞങ്ങൾ ലോഡ് ചെയ്യാൻ തീരുമാനിച്ചു ഡി 1. ഡിജിറ്റൽ 1C മുതൽ പരസ്യ കാമ്പെയ്‌നുകളും അവയ്ക്കുള്ളിലെ പ്ലെയ്‌സ്‌മെൻ്റുകളും സംബന്ധിച്ച വിവരങ്ങൾ, തുടർന്ന് ഈ പ്ലേസ്‌മെൻ്റുകളിലേക്ക് സൈറ്റുകളിൽ നിന്നും AdServing സിസ്റ്റങ്ങളിൽ നിന്നും സ്ഥിതിവിവരക്കണക്കുകൾ ശേഖരിക്കുക. ഇത് ഉപയോക്താക്കൾക്കുള്ള ജീവിതത്തെ ഗണ്യമായി ലഘൂകരിക്കേണ്ടതായിരുന്നു (കൂടാതെ, സാധാരണ പോലെ, ഡവലപ്പർമാർക്ക് കൂടുതൽ ജോലി ചേർക്കുക) പിന്തുണയുടെ അളവ് കുറയ്ക്കുക.

ഞങ്ങൾ നേരിട്ട ആദ്യത്തെ പ്രശ്നം ഒരു ഓർഗനൈസേഷണൽ സ്വഭാവമുള്ളതായിരുന്നു, വ്യത്യസ്ത സിസ്റ്റങ്ങളിൽ നിന്നുള്ള എൻ്റിറ്റികളെ 1C യിൽ നിന്നുള്ള കാമ്പെയ്‌നുകളും പ്ലെയ്‌സ്‌മെൻ്റുകളുമായി താരതമ്യം ചെയ്യാൻ ഞങ്ങൾക്ക് ഒരു കീയോ അടയാളമോ കണ്ടെത്താൻ കഴിഞ്ഞില്ല എന്ന വസ്തുതയുമായി ബന്ധപ്പെട്ടതാണ്. വ്യത്യസ്‌ത ആളുകൾ (മീഡിയ പ്ലാനർമാർ, വാങ്ങൽ മുതലായവ) പരസ്യ കാമ്പെയ്‌നുകൾ വ്യത്യസ്ത സംവിധാനങ്ങളിലേക്ക് പ്രവേശിക്കുന്ന തരത്തിലാണ് ഞങ്ങളുടെ കമ്പനിയിലെ പ്രക്രിയ രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്നത് എന്നതാണ് വസ്തുത.

ഈ പ്രശ്‌നം പരിഹരിക്കുന്നതിന്, വ്യത്യസ്ത സിസ്റ്റങ്ങളിലെ എൻ്റിറ്റികളെ ഒരുമിച്ച് ബന്ധിപ്പിക്കുന്ന, ഡൗൺലോഡ് ചെയ്‌ത ഡാറ്റാ സെറ്റുകളിൽ അത് വളരെ എളുപ്പത്തിലും അദ്വിതീയമായും തിരിച്ചറിയാൻ കഴിയുന്ന ഒരു അദ്വിതീയ ഹാഷ് കീ, DANBoID കണ്ടുപിടിക്കേണ്ടതുണ്ട്. ഈ ഐഡൻ്റിഫയർ ഓരോ വ്യക്തിഗത പ്ലെയ്‌സ്‌മെൻ്റിനുമായി ഇൻ്റേണൽ 1C സിസ്റ്റത്തിൽ ജനറേറ്റുചെയ്‌തിരിക്കുന്നു കൂടാതെ എല്ലാ സൈറ്റുകളിലും എല്ലാ AdServing സിസ്റ്റങ്ങളിലുമുള്ള കാമ്പെയ്‌നുകളിലേക്കും പ്ലെയ്‌സ്‌മെൻ്റുകളിലേക്കും കൗണ്ടറുകളിലേക്കും ഇത് കൈമാറുന്നു. എല്ലാ പ്ലെയ്‌സ്‌മെൻ്റുകളിലും DANBoID ഇടുന്ന രീതി നടപ്പിലാക്കാൻ കുറച്ച് സമയമെടുത്തു, പക്ഷേ ഞങ്ങൾക്ക് അത് ചെയ്യാൻ കഴിഞ്ഞു :)

സ്ഥിതിവിവരക്കണക്കുകൾ സ്വയമേവ ശേഖരിക്കുന്നതിന് എല്ലാ സൈറ്റുകൾക്കും ഒരു API ഇല്ലെന്നും ഒരു API ഉള്ളവ പോലും ആവശ്യമായ എല്ലാ ഡാറ്റയും നൽകുന്നില്ലെന്നും ഞങ്ങൾ കണ്ടെത്തി.

ഈ ഘട്ടത്തിൽ, സംയോജനത്തിനായുള്ള പ്ലാറ്റ്‌ഫോമുകളുടെ പട്ടിക ഗണ്യമായി കുറയ്ക്കാനും ബഹുഭൂരിപക്ഷം പരസ്യ കാമ്പെയ്‌നുകളിലും ഉൾപ്പെട്ടിരിക്കുന്ന പ്രധാന പ്ലാറ്റ്‌ഫോമുകളിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കാനും ഞങ്ങൾ തീരുമാനിച്ചു. ഈ പട്ടികയിൽ പരസ്യ വിപണിയിലെ (Google, Yandex, Mail.ru), സോഷ്യൽ നെറ്റ്‌വർക്കുകൾ (VK, Facebook, Twitter), പ്രധാന AdServing, അനലിറ്റിക്‌സ് സിസ്റ്റങ്ങൾ (DCM, Adriver, Weborama, Google Analytics) മറ്റ് പ്ലാറ്റ്‌ഫോമുകൾ എന്നിവയിലെ എല്ലാ വലിയ കളിക്കാരും ഉൾപ്പെടുന്നു.

ഞങ്ങൾ തിരഞ്ഞെടുത്ത ഭൂരിഭാഗം സൈറ്റുകളിലും ഞങ്ങൾക്ക് ആവശ്യമായ അളവുകൾ നൽകുന്ന ഒരു API ഉണ്ടായിരുന്നു. API ഇല്ലെങ്കിലോ അതിൽ ആവശ്യമായ ഡാറ്റ ഇല്ലെങ്കിലോ, ഡാറ്റ ലോഡുചെയ്യാൻ ഞങ്ങളുടെ ഓഫീസ് ഇമെയിലിലേക്ക് ദിവസേന അയയ്‌ക്കുന്ന റിപ്പോർട്ടുകൾ ഞങ്ങൾ ഉപയോഗിച്ചു (ചില സിസ്റ്റങ്ങളിൽ അത്തരം റിപ്പോർട്ടുകൾ കോൺഫിഗർ ചെയ്യാൻ കഴിയും, മറ്റുള്ളവയിൽ ഞങ്ങൾ അതിൻ്റെ വികസനം അംഗീകരിച്ചു. ഞങ്ങൾക്ക് അത്തരം റിപ്പോർട്ടുകൾ).

വ്യത്യസ്ത സൈറ്റുകളിൽ നിന്നുള്ള ഡാറ്റ വിശകലനം ചെയ്യുമ്പോൾ, വിവിധ സിസ്റ്റങ്ങളിൽ എൻ്റിറ്റികളുടെ ശ്രേണി ഒരുപോലെയല്ലെന്ന് ഞങ്ങൾ കണ്ടെത്തി. മാത്രമല്ല, വിവരങ്ങൾ വ്യത്യസ്ത സിസ്റ്റങ്ങളിൽ നിന്ന് വ്യത്യസ്ത വിശദമായി ഡൗൺലോഡ് ചെയ്യേണ്ടതുണ്ട്.

ഈ പ്രശ്നം പരിഹരിക്കാൻ, SubDANBoID ആശയം വികസിപ്പിച്ചെടുത്തു. SubDANBoID എന്ന ആശയം വളരെ ലളിതമാണ്, ഞങ്ങൾ സൈറ്റിലെ കാമ്പെയ്‌നിൻ്റെ പ്രധാന എൻ്റിറ്റിയെ ജനറേറ്റുചെയ്‌ത DANBoID ഉപയോഗിച്ച് അടയാളപ്പെടുത്തുന്നു, കൂടാതെ ഞങ്ങൾ എല്ലാ നെസ്റ്റഡ് എൻ്റിറ്റികളും തനതായ സൈറ്റ് ഐഡൻ്റിഫയറുകൾ ഉപയോഗിച്ച് അപ്‌ലോഡ് ചെയ്യുകയും DANBoID തത്വം + ആദ്യ ലെവലിൻ്റെ ഐഡൻ്റിഫയർ അനുസരിച്ച് SubDANBoID രൂപീകരിക്കുകയും ചെയ്യുന്നു. നെസ്റ്റഡ് എൻ്റിറ്റി + രണ്ടാം ലെവൽ നെസ്റ്റഡ് എൻ്റിറ്റിയുടെ ഐഡൻ്റിഫയർ +... ഈ സമീപനം വ്യത്യസ്ത സിസ്റ്റങ്ങളിൽ പരസ്യ കാമ്പെയ്‌നുകൾ ബന്ധിപ്പിക്കുന്നതിനും അവയിലെ വിശദമായ സ്ഥിതിവിവരക്കണക്കുകൾ ഡൗൺലോഡ് ചെയ്യുന്നതിനും ഞങ്ങളെ അനുവദിച്ചു.

വ്യത്യസ്ത പ്ലാറ്റ്‌ഫോമുകളിലെ കാമ്പെയ്‌നുകളിലേക്കുള്ള പ്രവേശനത്തിൻ്റെ പ്രശ്‌നവും ഞങ്ങൾക്ക് പരിഹരിക്കേണ്ടതുണ്ട്. ഞങ്ങൾ മുകളിൽ എഴുതിയതുപോലെ, ഒരു പ്രത്യേക സാങ്കേതിക അക്കൗണ്ടിലേക്ക് ഒരു കാമ്പെയ്‌നിലേക്കുള്ള ആക്‌സസ് ഡെലിഗേറ്റ് ചെയ്യുന്നതിനുള്ള സംവിധാനം എല്ലായ്പ്പോഴും ബാധകമല്ല. അതിനാൽ, ഈ ടോക്കണുകൾ അപ്‌ഡേറ്റ് ചെയ്യുന്നതിനുള്ള ടോക്കണുകളും മെക്കാനിസങ്ങളും ഉപയോഗിച്ച് OAuth വഴി യാന്ത്രിക അംഗീകാരത്തിനായി ഞങ്ങൾ ഒരു ഇൻഫ്രാസ്ട്രക്ചർ വികസിപ്പിക്കേണ്ടതുണ്ട്.

പിന്നീട് ലേഖനത്തിൽ ഞങ്ങൾ പരിഹാരത്തിൻ്റെ വാസ്തുവിദ്യയും നടപ്പാക്കലിൻ്റെ സാങ്കേതിക വിശദാംശങ്ങളും കൂടുതൽ വിശദമായി വിവരിക്കാൻ ശ്രമിക്കും.

സൊല്യൂഷൻ ആർക്കിടെക്ചർ 1.0

ഒരു പുതിയ ഉൽപ്പന്നം നടപ്പിലാക്കാൻ തുടങ്ങുമ്പോൾ, പുതിയ സൈറ്റുകൾ ബന്ധിപ്പിക്കുന്നതിനുള്ള സാധ്യത ഞങ്ങൾ ഉടനടി നൽകേണ്ടതുണ്ടെന്ന് ഞങ്ങൾ മനസ്സിലാക്കി, അതിനാൽ ഞങ്ങൾ മൈക്രോസർവീസ് ആർക്കിടെക്ചറിൻ്റെ പാത പിന്തുടരാൻ തീരുമാനിച്ചു.

ആർക്കിടെക്ചർ രൂപകൽപന ചെയ്യുമ്പോൾ, എല്ലാ ബാഹ്യ സിസ്റ്റങ്ങളിലേക്കും - 1C, പരസ്യ പ്ലാറ്റ്‌ഫോമുകൾ, പരസ്യ സംവിധാനങ്ങൾ എന്നിവയിലേക്കുള്ള കണക്ടറുകളെ ഞങ്ങൾ പ്രത്യേക സേവനങ്ങളായി വേർതിരിച്ചു.
സൈറ്റുകളിലേക്കുള്ള എല്ലാ കണക്ടർമാർക്കും ഒരേ API ഉണ്ടെന്നും സൈറ്റ് API-യെ ഞങ്ങൾക്ക് സൗകര്യപ്രദമായ ഒരു ഇൻ്റർഫേസിലേക്ക് കൊണ്ടുവരുന്ന അഡാപ്റ്ററുകൾ ആണെന്നുമാണ് പ്രധാന ആശയം.

ഞങ്ങളുടെ ഉൽപ്പന്നത്തിൻ്റെ മധ്യഭാഗത്ത് ഒരു വെബ് ആപ്ലിക്കേഷനാണ്, അത് സേവനങ്ങളിലേക്ക് എളുപ്പത്തിൽ വേർപെടുത്താൻ കഴിയുന്ന തരത്തിൽ രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്ന ഒരു മോണോലിത്ത് ആണ്. ഡൗൺലോഡ് ചെയ്‌ത ഡാറ്റ പ്രോസസ്സ് ചെയ്യുന്നതിനും വ്യത്യസ്ത സിസ്റ്റങ്ങളിൽ നിന്നുള്ള സ്ഥിതിവിവരക്കണക്കുകൾ ശേഖരിക്കുന്നതിനും സിസ്റ്റം ഉപയോക്താക്കൾക്ക് അവ അവതരിപ്പിക്കുന്നതിനും ഈ അപ്ലിക്കേഷൻ ഉത്തരവാദിയാണ്.

കണക്ടറുകളും വെബ് ആപ്ലിക്കേഷനും തമ്മിൽ ആശയവിനിമയം നടത്താൻ, ഞങ്ങൾ ഒരു അധിക സേവനം സൃഷ്ടിക്കേണ്ടതുണ്ട്, അതിനെ ഞങ്ങൾ കണക്റ്റർ പ്രോക്സി എന്ന് വിളിക്കുന്നു. ഇത് സർവീസ് ഡിസ്‌കവറി, ടാസ്‌ക് ഷെഡ്യൂളർ എന്നിവയുടെ പ്രവർത്തനങ്ങൾ ചെയ്യുന്നു. ഈ സേവനം എല്ലാ രാത്രിയിലും ഓരോ കണക്ടറിനും വേണ്ടി ഡാറ്റ ശേഖരണ ജോലികൾ നടത്തുന്നു. ഒരു സന്ദേശ ബ്രോക്കറെ ബന്ധിപ്പിക്കുന്നതിനേക്കാൾ ഒരു സേവന പാളി എഴുതുന്നത് എളുപ്പമായിരുന്നു, ഞങ്ങൾക്ക് കഴിയുന്നത്ര വേഗത്തിൽ ഫലം ലഭിക്കുന്നത് പ്രധാനമാണ്.

വികസനത്തിൻ്റെ ലാളിത്യത്തിനും വേഗതയ്ക്കും, എല്ലാ സേവനങ്ങളും വെബ് API-കളായിരിക്കുമെന്നും ഞങ്ങൾ തീരുമാനിച്ചു. ആശയത്തിൻ്റെ തെളിവ് വേഗത്തിൽ കൂട്ടിച്ചേർക്കാനും മുഴുവൻ രൂപകൽപ്പനയും പ്രവർത്തിക്കുന്നുവെന്ന് പരിശോധിക്കാനും ഇത് സാധ്യമാക്കി.

വ്യത്യസ്‌ത അക്കൗണ്ടുകളിൽ നിന്ന് ഡാറ്റ ശേഖരിക്കുന്നതിനുള്ള ആക്‌സസ് സജ്ജീകരിക്കുക എന്നത് മറ്റൊരു സങ്കീർണ്ണമായ ടാസ്‌ക് ആയിരുന്നു, ഞങ്ങൾ തീരുമാനിച്ചതുപോലെ വെബ് ഇൻ്റർഫേസ് വഴി ഉപയോക്താക്കൾ ഇത് നടപ്പിലാക്കണം. ഇതിൽ രണ്ട് വ്യത്യസ്ത ഘട്ടങ്ങൾ അടങ്ങിയിരിക്കുന്നു: ആദ്യം, OAuth വഴി അക്കൗണ്ട് ആക്‌സസ് ചെയ്യുന്നതിന് ഉപയോക്താവ് ഒരു ടോക്കൺ ചേർക്കുന്നു, തുടർന്ന് ഒരു നിർദ്ദിഷ്ട അക്കൗണ്ടിൽ നിന്ന് ക്ലയൻ്റിനായുള്ള ഡാറ്റ ശേഖരണം കോൺഫിഗർ ചെയ്യുന്നു. OAuth വഴി ഒരു ടോക്കൺ നേടേണ്ടത് അത്യാവശ്യമാണ്, കാരണം ഞങ്ങൾ ഇതിനകം എഴുതിയതുപോലെ, സൈറ്റിലെ ആവശ്യമുള്ള അക്കൗണ്ടിലേക്ക് ആക്സസ് ഡെലിഗേറ്റ് ചെയ്യുന്നത് എല്ലായ്പ്പോഴും സാധ്യമല്ല.

സൈറ്റുകളിൽ നിന്ന് ഒരു അക്കൗണ്ട് തിരഞ്ഞെടുക്കുന്നതിനുള്ള ഒരു സാർവത്രിക സംവിധാനം സൃഷ്ടിക്കുന്നതിന്, JSON സ്കീമ തിരികെ നൽകുന്ന കണക്ടർ API-യിലേക്ക് ഞങ്ങൾ ഒരു രീതി ചേർക്കേണ്ടതുണ്ട്, അത് പരിഷ്കരിച്ച JSONEditor ഘടകം ഉപയോഗിച്ച് ഒരു ഫോമിലേക്ക് റെൻഡർ ചെയ്യുന്നു. ഇതുവഴി, ഡാറ്റ ഡൗൺലോഡ് ചെയ്യേണ്ട അക്കൗണ്ടുകൾ തിരഞ്ഞെടുക്കാൻ ഉപയോക്താക്കൾക്ക് കഴിഞ്ഞു.

സൈറ്റുകളിൽ നിലവിലുള്ള അഭ്യർത്ഥന പരിധികൾ അനുസരിക്കുന്നതിന്, ഒരു ടോക്കണിനുള്ളിൽ ക്രമീകരണങ്ങൾക്കായുള്ള അഭ്യർത്ഥനകൾ ഞങ്ങൾ സംയോജിപ്പിക്കുന്നു, എന്നാൽ നമുക്ക് സമാന്തരമായി വ്യത്യസ്ത ടോക്കണുകൾ പ്രോസസ്സ് ചെയ്യാൻ കഴിയും.

വെബ് ആപ്ലിക്കേഷനും കണക്ടറുകൾക്കുമായി ലോഡ് ചെയ്ത ഡാറ്റയ്ക്കുള്ള സംഭരണമായി ഞങ്ങൾ മോംഗോഡിബി തിരഞ്ഞെടുത്തു, ഇത് വികസനത്തിൻ്റെ പ്രാരംഭ ഘട്ടത്തിൽ, ആപ്ലിക്കേഷൻ്റെ ഒബ്‌ജക്റ്റ് മോഡൽ മറ്റെല്ലാ ദിവസവും മാറുമ്പോൾ ഡാറ്റാ ഘടനയെക്കുറിച്ച് വളരെയധികം വിഷമിക്കേണ്ടതില്ല.

മോംഗോഡിബിയിൽ എല്ലാ ഡാറ്റയും നന്നായി യോജിക്കുന്നില്ലെന്ന് ഞങ്ങൾ ഉടൻ കണ്ടെത്തി, ഉദാഹരണത്തിന്, ഒരു റിലേഷണൽ ഡാറ്റാബേസിൽ ദൈനംദിന സ്ഥിതിവിവരക്കണക്കുകൾ സൂക്ഷിക്കുന്നത് കൂടുതൽ സൗകര്യപ്രദമാണ്. അതിനാൽ, ഒരു റിലേഷണൽ ഡാറ്റാബേസിന് കൂടുതൽ അനുയോജ്യമായ ഡാറ്റാ ഘടനയുള്ള കണക്ടറുകൾക്കായി, ഞങ്ങൾ PostgreSQL അല്ലെങ്കിൽ MS SQL സെർവർ സ്റ്റോറേജായി ഉപയോഗിക്കാൻ തുടങ്ങി.

തിരഞ്ഞെടുത്ത വാസ്തുവിദ്യയും സാങ്കേതികവിദ്യകളും D1.Digital ഉൽപ്പന്നം താരതമ്യേന വേഗത്തിൽ നിർമ്മിക്കാനും സമാരംഭിക്കാനും ഞങ്ങളെ അനുവദിച്ചു. രണ്ട് വർഷത്തെ ഉൽപ്പന്ന വികസനത്തിൽ, ഞങ്ങൾ സൈറ്റുകളിലേക്ക് 23 കണക്ടറുകൾ വികസിപ്പിച്ചെടുത്തു, മൂന്നാം കക്ഷി API-കളിൽ പ്രവർത്തിച്ച് വിലമതിക്കാനാവാത്ത അനുഭവം നേടി, ഓരോന്നിനും സ്വന്തമായി ഉണ്ടായിരുന്ന വ്യത്യസ്ത സൈറ്റുകളുടെ അപകടങ്ങൾ ഒഴിവാക്കാൻ പഠിച്ചു, കുറഞ്ഞത് 3 API യുടെ വികസനത്തിന് സംഭാവന നൽകി. സൈറ്റുകൾ, ഏകദേശം 15 കാമ്പെയ്‌നുകളുടെയും 000-ലധികം പ്ലെയ്‌സ്‌മെൻ്റുകളുടെയും വിവരങ്ങൾ സ്വയമേവ ഡൗൺലോഡ് ചെയ്‌തു, ഉൽപ്പന്നത്തിൻ്റെ പ്രവർത്തനത്തെക്കുറിച്ച് ഉപയോക്താക്കളിൽ നിന്ന് ധാരാളം ഫീഡ്‌ബാക്ക് ശേഖരിക്കുകയും ഈ ഫീഡ്‌ബാക്കിൻ്റെ അടിസ്ഥാനത്തിൽ ഉൽപ്പന്നത്തിൻ്റെ പ്രധാന പ്രക്രിയ നിരവധി തവണ മാറ്റുകയും ചെയ്തു.

സൊല്യൂഷൻ ആർക്കിടെക്ചർ 2.0

വികസനം തുടങ്ങിയിട്ട് രണ്ട് വർഷം കഴിഞ്ഞു ഡി 1. ഡിജിറ്റൽ. സിസ്റ്റത്തിലെ ലോഡിലെ നിരന്തരമായ വർദ്ധനവും കൂടുതൽ കൂടുതൽ പുതിയ ഡാറ്റ സ്രോതസ്സുകളുടെ ആവിർഭാവവും നിലവിലുള്ള സൊല്യൂഷൻ ആർക്കിടെക്ചറിലെ പ്രശ്നങ്ങൾ ക്രമേണ വെളിപ്പെടുത്തി.

സൈറ്റുകളിൽ നിന്ന് ഡൗൺലോഡ് ചെയ്ത ഡാറ്റയുടെ അളവുമായി ബന്ധപ്പെട്ടതാണ് ആദ്യത്തെ പ്രശ്നം. ഏറ്റവും വലിയ സൈറ്റുകളിൽ നിന്ന് ആവശ്യമായ എല്ലാ ഡാറ്റയും ശേഖരിക്കുന്നതിനും അപ്‌ഡേറ്റ് ചെയ്യുന്നതിനും വളരെയധികം സമയമെടുക്കുന്നു എന്ന വസ്തുത ഞങ്ങൾ അഭിമുഖീകരിച്ചു. ഉദാഹരണത്തിന്, മിക്ക പ്ലെയ്‌സ്‌മെൻ്റുകളുടെയും സ്ഥിതിവിവരക്കണക്കുകൾ ഞങ്ങൾ ട്രാക്ക് ചെയ്യുന്ന AdRiver പരസ്യ സംവിധാനത്തിൽ നിന്ന് ഡാറ്റ ശേഖരിക്കുന്നതിന് ഏകദേശം 12 മണിക്കൂർ എടുക്കും.

ഈ പ്രശ്നം പരിഹരിക്കുന്നതിന്, സൈറ്റുകളിൽ നിന്ന് ഡാറ്റ ഡൗൺലോഡ് ചെയ്യുന്നതിന് ഞങ്ങൾ എല്ലാത്തരം റിപ്പോർട്ടുകളും ഉപയോഗിക്കാൻ തുടങ്ങി, സൈറ്റുകൾക്കൊപ്പം അവരുടെ API വികസിപ്പിക്കാൻ ഞങ്ങൾ ശ്രമിക്കുന്നു, അതിലൂടെ അതിൻ്റെ പ്രവർത്തനത്തിൻ്റെ വേഗത ഞങ്ങളുടെ ആവശ്യങ്ങൾ നിറവേറ്റുകയും ഡാറ്റ ഡൗൺലോഡ് കഴിയുന്നത്ര സമാന്തരമാക്കുകയും ചെയ്യുന്നു.

ഡൗൺലോഡ് ചെയ്ത ഡാറ്റയുടെ പ്രോസസ്സിംഗുമായി ബന്ധപ്പെട്ട മറ്റൊരു പ്രശ്നം. ഇപ്പോൾ, പുതിയ പ്ലെയ്‌സ്‌മെൻ്റ് സ്ഥിതിവിവരക്കണക്കുകൾ വരുമ്പോൾ, മെട്രിക്‌സ് വീണ്ടും കണക്കാക്കുന്നതിനുള്ള ഒരു മൾട്ടി-സ്റ്റേജ് പ്രോസസ്സ് ആരംഭിക്കുന്നു, അതിൽ അസംസ്‌കൃത ഡാറ്റ ലോഡുചെയ്യൽ, ഓരോ സൈറ്റിനും മൊത്തത്തിലുള്ള മെട്രിക്‌സ് കണക്കാക്കൽ, വ്യത്യസ്ത ഉറവിടങ്ങളിൽ നിന്നുള്ള ഡാറ്റ പരസ്പരം താരതമ്യം ചെയ്യൽ, കാമ്പെയ്‌നിനായി സംഗ്രഹ മെട്രിക്‌സ് കണക്കാക്കൽ എന്നിവ ഉൾപ്പെടുന്നു. എല്ലാ കണക്കുകൂട്ടലുകളും ചെയ്യുന്ന വെബ് ആപ്ലിക്കേഷനിൽ ഇത് വളരെയധികം ലോഡ് ഉണ്ടാക്കുന്നു. നിരവധി തവണ, വീണ്ടും കണക്കുകൂട്ടൽ പ്രക്രിയയിൽ, ആപ്ലിക്കേഷൻ സെർവറിലെ എല്ലാ മെമ്മറിയും ഉപഭോഗം ചെയ്തു, ഏകദേശം 10-15 GB, ഇത് സിസ്റ്റവുമായുള്ള ഉപയോക്താക്കളുടെ പ്രവർത്തനത്തെ ഏറ്റവും ദോഷകരമായി ബാധിച്ചു.

കണ്ടെത്തിയ പ്രശ്‌നങ്ങളും ഉൽപ്പന്നത്തിൻ്റെ കൂടുതൽ വികസനത്തിനായുള്ള അതിമോഹമായ പദ്ധതികളും ആപ്ലിക്കേഷൻ ആർക്കിടെക്ചർ പുനർവിചിന്തനം ചെയ്യേണ്ടതിൻ്റെ ആവശ്യകതയിലേക്ക് ഞങ്ങളെ നയിച്ചു.

ഞങ്ങൾ കണക്റ്ററുകൾ ഉപയോഗിച്ച് ആരംഭിച്ചു.
എല്ലാ കണക്ടറുകളും ഒരേ മോഡലിന് അനുസൃതമായി പ്രവർത്തിക്കുന്നത് ഞങ്ങൾ ശ്രദ്ധിച്ചു, അതിനാൽ ഞങ്ങൾ ഒരു പൈപ്പ്ലൈൻ ചട്ടക്കൂട് നിർമ്മിച്ചു, അതിൽ ഒരു കണക്റ്റർ സൃഷ്ടിക്കാൻ നിങ്ങൾക്ക് ഘട്ടങ്ങളുടെ ലോജിക് പ്രോഗ്രാം ചെയ്യണം, ബാക്കിയുള്ളവ സാർവത്രികമായിരുന്നു. ചില കണക്ടറിന് മെച്ചപ്പെടുത്തൽ ആവശ്യമാണെങ്കിൽ, കണക്റ്റർ മെച്ചപ്പെടുത്തുന്ന അതേ സമയം തന്നെ ഞങ്ങൾ അത് ഒരു പുതിയ ചട്ടക്കൂടിലേക്ക് മാറ്റുന്നു.

അതേ സമയം, ഞങ്ങൾ ഡോക്കറിലേക്കും കുബർനെറ്റസിലേക്കും കണക്ടറുകൾ വിന്യസിക്കാൻ തുടങ്ങി.
CI/CD ക്രമീകരണങ്ങൾ ഉപയോഗിച്ച് ഞങ്ങൾ വളരെക്കാലമായി കുബർനെറ്റസിലേക്കുള്ള നീക്കം ആസൂത്രണം ചെയ്തു, പക്ഷേ ഒരു കണക്റ്റർ, ഒരു പിശക് കാരണം, സെർവറിലെ 20 GB-ൽ കൂടുതൽ മെമ്മറി നശിപ്പിക്കാൻ തുടങ്ങിയപ്പോൾ മാത്രം നീങ്ങാൻ തുടങ്ങി, ഇത് പ്രായോഗികമായി മറ്റ് പ്രക്രിയകളെ ഇല്ലാതാക്കുന്നു. . അന്വേഷണത്തിനിടയിൽ, കണക്റ്റർ ഒരു കുബർനെറ്റസ് ക്ലസ്റ്ററിലേക്ക് മാറ്റി, പിശക് പരിഹരിച്ചതിന് ശേഷവും അത് ആത്യന്തികമായി തുടർന്നു.

കുബർനെറ്റസ് സൗകര്യപ്രദമാണെന്ന് ഞങ്ങൾ വളരെ വേഗം മനസ്സിലാക്കി, ആറ് മാസത്തിനുള്ളിൽ ഞങ്ങൾ ഏറ്റവും കൂടുതൽ വിഭവങ്ങൾ ഉപയോഗിക്കുന്ന 7 കണക്റ്ററുകളും കണക്ടർ പ്രോക്സിയും പ്രൊഡക്ഷൻ ക്ലസ്റ്ററിലേക്ക് മാറ്റി.

കണക്ടറുകൾ പിന്തുടർന്ന്, ബാക്കിയുള്ള ആപ്ലിക്കേഷൻ്റെ ആർക്കിടെക്ചർ മാറ്റാൻ ഞങ്ങൾ തീരുമാനിച്ചു.
കണക്റ്ററുകളിൽ നിന്ന് വലിയ ബാച്ചുകളിൽ പ്രോക്സികളിലേക്ക് ഡാറ്റ വരുന്നു, തുടർന്ന് DANBoID-ൽ ഹിറ്റ് ചെയ്യുകയും പ്രോസസ്സിംഗിനായി സെൻട്രൽ വെബ് ആപ്ലിക്കേഷനിലേക്ക് അയയ്ക്കുകയും ചെയ്യുന്നതാണ് പ്രധാന പ്രശ്നം. മെട്രിക്സ് വീണ്ടും കണക്കുകൂട്ടലുകളുടെ എണ്ണം കൂടുതലായതിനാൽ, ആപ്ലിക്കേഷനിൽ ഒരു വലിയ ലോഡ് ഉണ്ട്.

വ്യക്തിഗത ഡാറ്റാ ശേഖരണ ജോലികളുടെ നില നിരീക്ഷിക്കുന്നതും ഒരു സെൻട്രൽ വെബ് ആപ്ലിക്കേഷനിലേക്ക് കണക്റ്ററുകൾക്കുള്ളിൽ സംഭവിക്കുന്ന പിശകുകൾ റിപ്പോർട്ട് ചെയ്യുന്നതും വളരെ ബുദ്ധിമുട്ടുള്ളതായി തെളിഞ്ഞു, അതിലൂടെ ഉപയോക്താക്കൾക്ക് എന്താണ് സംഭവിക്കുന്നതെന്നും എന്തുകൊണ്ട് ഡാറ്റ ശേഖരിക്കുന്നില്ലെന്നും കാണാനാകും.

ഈ പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നതിന്, ഞങ്ങൾ ആർക്കിടെക്ചർ 2.0 വികസിപ്പിച്ചെടുത്തു.

ആർക്കിടെക്ചറിൻ്റെ പുതിയ പതിപ്പ് തമ്മിലുള്ള പ്രധാന വ്യത്യാസം, സേവനങ്ങൾക്കിടയിൽ സന്ദേശങ്ങൾ കൈമാറാൻ Web API-ക്ക് പകരം RabbitMQ, MassTransit ലൈബ്രറി എന്നിവ ഉപയോഗിക്കുന്നു എന്നതാണ്. ഇത് ചെയ്യുന്നതിന്, കണക്റ്റേഴ്സ് പ്രോക്സിയെ ഞങ്ങൾ ഏതാണ്ട് പൂർണ്ണമായും മാറ്റിയെഴുതേണ്ടതുണ്ട്, അത് കണക്ടേഴ്സ് ഹബ് ആക്കി. സേവനത്തിൻ്റെ പ്രധാന പങ്ക് കണക്റ്ററുകളിലേക്കും തിരിച്ചും അഭ്യർത്ഥനകൾ കൈമാറുന്നതിലല്ല, മറിച്ച് കണക്റ്ററുകളിൽ നിന്നുള്ള മെട്രിക്‌സ് ശേഖരണം നിയന്ത്രിക്കുന്നതിലാണ് ഈ പേര് മാറ്റിയത്.

സെൻട്രൽ വെബ് ആപ്ലിക്കേഷനിൽ നിന്ന്, സൈറ്റുകളിൽ നിന്നുള്ള പ്ലെയ്‌സ്‌മെൻ്റുകളെയും സ്ഥിതിവിവരക്കണക്കുകളെയും കുറിച്ചുള്ള വിവരങ്ങൾ ഞങ്ങൾ പ്രത്യേക സേവനങ്ങളായി വേർതിരിച്ചു, ഇത് അനാവശ്യമായ കണക്കുകൂട്ടലുകൾ ഒഴിവാക്കാനും പ്ലേസ്‌മെൻ്റ് തലത്തിൽ ഇതിനകം കണക്കാക്കിയതും സമാഹരിച്ചതുമായ സ്ഥിതിവിവരക്കണക്കുകൾ മാത്രം സംഭരിക്കാനും സാധ്യമാക്കി. അസംസ്‌കൃത ഡാറ്റയെ അടിസ്ഥാനമാക്കി അടിസ്ഥാന സ്ഥിതിവിവരക്കണക്കുകൾ കണക്കാക്കുന്നതിനുള്ള ലോജിക് ഞങ്ങൾ വീണ്ടും എഴുതുകയും ഒപ്റ്റിമൈസ് ചെയ്യുകയും ചെയ്തു.

അതേ സമയം, സൊല്യൂഷൻ സ്കെയിൽ ചെയ്യാൻ എളുപ്പമുള്ളതും കൈകാര്യം ചെയ്യാൻ കൂടുതൽ സൗകര്യപ്രദവുമാക്കുന്നതിന് ഞങ്ങൾ എല്ലാ സേവനങ്ങളും ആപ്ലിക്കേഷനുകളും ഡോക്കറിലേക്കും കുബർനെറ്റിലേക്കും മൈഗ്രേറ്റ് ചെയ്യുന്നു.

നമ്മൾ ഇപ്പോൾ എവിടെയാണ്

പ്രൂഫ് ഓഫ് കൺസെപ്റ്റ് ആർക്കിടെക്ചർ 2.0 ഉൽപ്പന്നം ഡി 1. ഡിജിറ്റൽ പരിമിതമായ കണക്ടറുകളുള്ള ഒരു ടെസ്റ്റ് പരിതസ്ഥിതിയിൽ തയ്യാറായി പ്രവർത്തിക്കുന്നു. ഒരു പുതിയ പ്ലാറ്റ്‌ഫോമിലേക്ക് മറ്റൊരു 20 കണക്ടറുകൾ മാറ്റിയെഴുതുക, ഡാറ്റ ശരിയായി ലോഡുചെയ്‌തിട്ടുണ്ടെന്നും എല്ലാ മെട്രിക്കുകളും ശരിയായി കണക്കാക്കിയിട്ടുണ്ടോ എന്നും പരിശോധിച്ച് മുഴുവൻ ഡിസൈനും പ്രൊഡക്ഷനിലേക്ക് മാറ്റുക മാത്രമാണ് ഇനി ചെയ്യാനുള്ളത്.

വാസ്തവത്തിൽ, ഈ പ്രക്രിയ ക്രമേണ സംഭവിക്കും, എല്ലാം പ്രവർത്തിക്കാൻ ഞങ്ങൾ പഴയ API-കളുമായുള്ള പിന്നോക്ക അനുയോജ്യത ഉപേക്ഷിക്കേണ്ടിവരും.

പുതിയ കണക്ടറുകളുടെ വികസനം, പുതിയ സിസ്റ്റങ്ങളുമായുള്ള സംയോജനം, കണക്റ്റുചെയ്‌ത സൈറ്റുകളിൽ നിന്നും പരസ്യ സംവിധാനങ്ങളിൽ നിന്നും ഡൗൺലോഡ് ചെയ്‌ത ഡാറ്റയുടെ സെറ്റിലേക്ക് അധിക മെട്രിക്‌സ് ചേർക്കുന്നതും ഞങ്ങളുടെ ഉടനടിയുള്ള പ്ലാനുകളിൽ ഉൾപ്പെടുന്നു.

സെൻട്രൽ വെബ് ആപ്ലിക്കേഷൻ ഉൾപ്പെടെ എല്ലാ ആപ്ലിക്കേഷനുകളും ഡോക്കറിനും കുബർനെറ്റസിനും കൈമാറാനും ഞങ്ങൾ പദ്ധതിയിടുന്നു. പുതിയ വാസ്തുവിദ്യയുമായി സംയോജിപ്പിച്ച്, ഇത് ഉപഭോഗ വിഭവങ്ങളുടെ വിന്യാസവും നിരീക്ഷണവും നിയന്ത്രണവും ഗണ്യമായി ലളിതമാക്കും.

സ്ഥിതിവിവരക്കണക്കുകൾ സംഭരിക്കുന്നതിന് ഡാറ്റാബേസ് തിരഞ്ഞെടുക്കുന്നത് പരീക്ഷിക്കുക എന്നതാണ് മറ്റൊരു ആശയം, അത് നിലവിൽ മോംഗോഡിബിയിൽ സംഭരിച്ചിരിക്കുന്നു. ഞങ്ങൾ ഇതിനകം നിരവധി പുതിയ കണക്ടറുകൾ SQL ഡാറ്റാബേസുകളിലേക്ക് ട്രാൻസ്ഫർ ചെയ്തിട്ടുണ്ട്, എന്നാൽ അവിടെ വ്യത്യാസം ഏതാണ്ട് അജ്ഞാതമാണ്, കൂടാതെ ഏകപക്ഷീയമായ ഒരു കാലയളവിനായി അഭ്യർത്ഥിക്കാവുന്ന ദിവസം അനുസരിച്ച് സംഗ്രഹിച്ച സ്ഥിതിവിവരക്കണക്കുകൾക്ക്, നേട്ടം വളരെ ഗുരുതരമായേക്കാം.

പൊതുവേ, പദ്ധതികൾ ഗംഭീരമാണ്, നമുക്ക് മുന്നോട്ട് പോകാം :)

ലേഖനത്തിൻ്റെ രചയിതാക്കൾ R&D Dentsu Aegis Network Russia: Georgy Ostapenko (shmigaa), മിഖായേൽ കോട്‌സിക് (ഹിറ്റെക്സ്)

അവലംബം: www.habr.com