ஆன்லைன் தளங்களில் இருந்து விளம்பரப் பிரச்சாரங்களின் தரவை நாங்கள் எவ்வாறு சேகரித்தோம் (தயாரிப்புக்கான முட்கள் நிறைந்த பாதை)

ஆன்லைன் விளம்பரத் துறையானது தொழில்நுட்ப ரீதியாக மேம்பட்டதாகவும், தன்னியக்கமானதாகவும் இருக்க வேண்டும் என்று தோன்றுகிறது. நிச்சயமாக, Yandex, Mail.Ru, Google மற்றும் Facebook போன்ற ராட்சதர்கள் மற்றும் அவர்களின் துறையில் வல்லுநர்கள் அங்கு வேலை செய்கிறார்கள். ஆனால், அது மாறியது போல், பரிபூரணத்திற்கு வரம்பு இல்லை மற்றும் தானியங்கு செய்ய எப்போதும் ஏதாவது இருக்கிறது.

மூல

தொடர்பு குழு டென்சு ஏஜிஸ் நெட்வொர்க் ரஷ்யா டிஜிட்டல் விளம்பர சந்தையில் மிகப்பெரிய வீரர் மற்றும் தொழில்நுட்பத்தில் தீவிரமாக முதலீடு செய்து, அதன் வணிக செயல்முறைகளை மேம்படுத்தவும் தானியங்குபடுத்தவும் முயற்சிக்கிறது. ஆன்லைன் விளம்பர சந்தையின் தீர்க்கப்படாத சிக்கல்களில் ஒன்று வெவ்வேறு இணைய தளங்களில் இருந்து விளம்பர பிரச்சாரங்கள் பற்றிய புள்ளிவிவரங்களை சேகரிக்கும் பணியாக மாறியுள்ளது. இந்த சிக்கலுக்கான தீர்வு இறுதியில் ஒரு தயாரிப்பை உருவாக்கியது டி 1. டிஜிட்டல் (திவான் என வாசிக்கவும்), அதன் வளர்ச்சி பற்றி நாம் பேச விரும்புகிறோம்.

ஏன்?

1. திட்டம் தொடங்கும் நேரத்தில், விளம்பர பிரச்சாரங்களில் புள்ளிவிவரங்களை சேகரிப்பதை தானியங்குபடுத்தும் சிக்கலை தீர்க்கும் ஒரு ஆயத்த தயாரிப்பு சந்தையில் இல்லை. நம்மைத் தவிர வேறு யாரும் நம் தேவைகளைப் பூர்த்தி செய்ய மாட்டார்கள் என்பதே இதன் பொருள்.

Improvado, Roistat, Supermetrics, SegmentStream போன்ற சேவைகள் தளங்கள், சமூக வலைப்பின்னல்கள் மற்றும் கூகுள் அனலிட்டிக்ஸ் ஆகியவற்றுடன் ஒருங்கிணைப்பை வழங்குகின்றன, மேலும் வசதியான பகுப்பாய்வு மற்றும் விளம்பரப் பிரச்சாரங்களின் கட்டுப்பாட்டிற்காக பகுப்பாய்வு டாஷ்போர்டுகளை உருவாக்குவதை சாத்தியமாக்குகின்றன. நாங்கள் எங்கள் தயாரிப்பை உருவாக்கத் தொடங்குவதற்கு முன், தளங்களிலிருந்து தரவைச் சேகரிக்க இந்த அமைப்புகளில் சிலவற்றைப் பயன்படுத்த முயற்சித்தோம், ஆனால், துரதிர்ஷ்டவசமாக, அவர்களால் எங்கள் சிக்கல்களைத் தீர்க்க முடியவில்லை.

முக்கிய பிரச்சனை என்னவென்றால், சோதனை செய்யப்பட்ட தயாரிப்புகள் தரவு மூலங்களை நம்பியிருந்தன, தளம் வாரியாக வேலை வாய்ப்பு புள்ளிவிவரங்களைக் காட்டுகின்றன, மேலும் விளம்பர பிரச்சாரங்களில் புள்ளிவிவரங்களை ஒருங்கிணைக்கும் திறனை வழங்கவில்லை. இந்த அணுகுமுறை வெவ்வேறு தளங்களின் புள்ளிவிவரங்களை ஒரே இடத்தில் பார்க்கவும், ஒட்டுமொத்த பிரச்சாரத்தின் நிலையை பகுப்பாய்வு செய்யவும் அனுமதிக்கவில்லை.

மற்றொரு காரணி என்னவென்றால், ஆரம்ப கட்டங்களில் தயாரிப்புகள் மேற்கத்திய சந்தையை இலக்காகக் கொண்டிருந்தன மற்றும் ரஷ்ய தளங்களுடன் ஒருங்கிணைப்பதை ஆதரிக்கவில்லை. ஒருங்கிணைப்பு செயல்படுத்தப்பட்ட தளங்களுக்கு, தேவையான அனைத்து அளவீடுகளும் எப்போதும் போதுமான விவரங்களுடன் பதிவிறக்கம் செய்யப்படவில்லை, மேலும் ஒருங்கிணைப்பு எப்போதும் வசதியாகவும் வெளிப்படையாகவும் இருக்காது, குறிப்பாக கணினி இடைமுகத்தில் இல்லாத ஒன்றைப் பெற வேண்டிய அவசியம் ஏற்பட்டால்.
பொதுவாக, நாங்கள் மூன்றாம் தரப்பு தயாரிப்புகளுக்கு மாற்றியமைக்க வேண்டாம் என்று முடிவு செய்தோம், ஆனால் சொந்தமாக உருவாக்கத் தொடங்கினோம்.

2. ஆன்லைன் விளம்பர சந்தை ஆண்டுக்கு ஆண்டு வளர்ந்து வருகிறது, மேலும் 2018 இல், விளம்பர வரவு செலவுத் திட்டங்களின் அடிப்படையில், பாரம்பரியமாக மிகப்பெரிய டிவி விளம்பர சந்தையை முந்தியது. எனவே ஒரு அளவு உள்ளது.

3. தொலைக்காட்சி விளம்பர சந்தையைப் போலன்றி, வணிக விளம்பரங்களின் விற்பனை ஏகபோகமாக உள்ளது, இணையத்தில் பல்வேறு அளவுகளில் விளம்பர சரக்குகளின் தனிப்பட்ட உரிமையாளர்கள் தங்கள் சொந்த விளம்பரக் கணக்குகளுடன் செயல்படுகின்றனர். ஒரு விளம்பரப் பிரச்சாரம், ஒரு விதியாக, ஒரே நேரத்தில் பல தளங்களில் இயங்குவதால், விளம்பரப் பிரச்சாரத்தின் நிலையைப் புரிந்து கொள்ள, எல்லா தளங்களிலிருந்தும் அறிக்கைகளைச் சேகரித்து, முழுப் படத்தையும் காண்பிக்கும் ஒரு பெரிய அறிக்கையாக அவற்றை இணைக்க வேண்டியது அவசியம். இதன் பொருள் தேர்வுமுறைக்கான சாத்தியம் உள்ளது.

4. இணையத்தில் உள்ள விளம்பர சரக்குகளின் உரிமையாளர்கள் ஏற்கனவே புள்ளிவிவரங்களைச் சேகரித்து அவற்றை விளம்பரக் கணக்குகளில் காண்பிப்பதற்கான உள்கட்டமைப்பைக் கொண்டிருப்பதாக எங்களுக்குத் தோன்றியது, மேலும் அவர்கள் இந்தத் தரவிற்கான API ஐ வழங்க முடியும். இதன் பொருள் தொழில்நுட்ப ரீதியாக அதை செயல்படுத்துவது சாத்தியமாகும். அது அவ்வளவு எளிதல்ல என்று இப்போதே சொல்லலாம்.

பொதுவாக, திட்டத்தை செயல்படுத்துவதற்கான அனைத்து முன்நிபந்தனைகளும் எங்களுக்குத் தெளிவாக இருந்தன, மேலும் திட்டத்தை உயிர்ப்பிக்க நாங்கள் ஓடினோம் ...

பெரிய திட்டம்

தொடங்குவதற்கு, நாங்கள் ஒரு சிறந்த அமைப்பின் பார்வையை உருவாக்கினோம்:

• 1C கார்ப்பரேட் அமைப்பின் விளம்பரப் பிரச்சாரங்கள், அவற்றின் பெயர்கள், காலகட்டங்கள், வரவு செலவுத் திட்டங்கள் மற்றும் பல்வேறு தளங்களில் உள்ள இடங்கள் ஆகியவற்றுடன் தானாகவே அதில் ஏற்றப்பட வேண்டும்.
• ஒரு விளம்பரப் பிரச்சாரத்தில் உள்ள ஒவ்வொரு இடத்துக்கும், பதிவுகள், கிளிக்குகள், பார்வைகள் போன்ற இடங்கள் நடைபெறும் தளங்களிலிருந்து சாத்தியமான அனைத்து புள்ளிவிவரங்களும் தானாகவே பதிவிறக்கம் செய்யப்பட வேண்டும்.
• Adriver, Weborama, DCM போன்ற விளம்பர அமைப்புகள் எனப்படும் மூன்றாம் தரப்பு கண்காணிப்பைப் பயன்படுத்தி சில விளம்பரப் பிரச்சாரங்கள் கண்காணிக்கப்படுகின்றன. ரஷ்யாவில் ஒரு தொழில்துறை இணைய மீட்டர் உள்ளது - மீடியாஸ்கோப் நிறுவனம். எங்கள் திட்டத்தின்படி, சுயாதீனமான மற்றும் தொழில்துறை கண்காணிப்பில் இருந்து தரவும் தானாகவே தொடர்புடைய விளம்பர பிரச்சாரங்களில் ஏற்றப்பட வேண்டும்.
• இணையத்தில் உள்ள பெரும்பாலான விளம்பரப் பிரச்சாரங்கள், Google Analytics ஐப் பயன்படுத்தி கண்காணிக்கப்படும் சில இலக்கு செயல்களை (வாங்குதல், அழைப்பு, சோதனை இயக்ககத்திற்கு பதிவுபெறுதல் போன்றவை) இலக்காகக் கொண்டவை. எங்கள் கருவியில் ஏற்றப்பட வேண்டும்.

முதல் பான்காரம் கட்டி முடிக்கப்படுகிறது

மென்பொருள் மேம்பாட்டின் நெகிழ்வான கொள்கைகளுக்கு (சுறுசுறுப்பான, எல்லா விஷயங்களிலும்) எங்கள் அர்ப்பணிப்பைக் கருத்தில் கொண்டு, முதலில் ஒரு MVP ஐ உருவாக்க முடிவு செய்தோம், பின்னர் மீண்டும் உத்தேசித்த இலக்கை நோக்கி நகர்த்தினோம்.
எங்கள் தயாரிப்பின் அடிப்படையில் எம்விபியை உருவாக்க முடிவு செய்தோம் DANBo (Dentsu Aegis நெட்வொர்க் போர்டு), இது எங்கள் வாடிக்கையாளர்களின் விளம்பரப் பிரச்சாரங்கள் குறித்த பொதுவான தகவல்களுடன் கூடிய வலைப் பயன்பாடு ஆகும்.

MVP க்கு, திட்டம் செயல்படுத்தும் வகையில் முடிந்தவரை எளிமைப்படுத்தப்பட்டது. ஒருங்கிணைந்த தளங்களின் வரையறுக்கப்பட்ட பட்டியலை நாங்கள் தேர்ந்தெடுத்துள்ளோம். 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 ஐ உருவாக்குகிறோம். nested entity + identifier of the second level nested entity +... இந்த அணுகுமுறையானது வெவ்வேறு அமைப்புகளில் விளம்பரப் பிரச்சாரங்களை இணைக்கவும், அவற்றைப் பற்றிய விரிவான புள்ளிவிவரங்களைப் பதிவிறக்கவும் எங்களை அனுமதித்தது.

வெவ்வேறு தளங்களில் பிரச்சாரங்களை அணுகுவதற்கான சிக்கலையும் நாங்கள் தீர்க்க வேண்டியிருந்தது. நாங்கள் மேலே எழுதியது போல, ஒரு பிரச்சாரத்திற்கான அணுகலை ஒரு தனி தொழில்நுட்ப கணக்கிற்கு வழங்குவதற்கான வழிமுறை எப்போதும் பொருந்தாது. எனவே, இந்த டோக்கன்களைப் புதுப்பிப்பதற்கான டோக்கன்கள் மற்றும் வழிமுறைகளைப் பயன்படுத்தி OAuth வழியாக தானியங்கி அங்கீகாரத்திற்கான உள்கட்டமைப்பை நாங்கள் உருவாக்க வேண்டியிருந்தது.

பின்னர் கட்டுரையில் தீர்வின் கட்டமைப்பு மற்றும் செயல்படுத்தலின் தொழில்நுட்ப விவரங்களை இன்னும் விரிவாக விவரிக்க முயற்சிப்போம்.

தீர்வு கட்டமைப்பு 1.0

ஒரு புதிய தயாரிப்பை செயல்படுத்தத் தொடங்கும் போது, ​​புதிய தளங்களை இணைப்பதற்கான சாத்தியத்தை உடனடியாக வழங்க வேண்டும் என்பதை நாங்கள் புரிந்துகொண்டோம், எனவே மைக்ரோ சர்வீஸ் கட்டமைப்பின் பாதையைப் பின்பற்ற முடிவு செய்தோம்.

கட்டிடக்கலை வடிவமைக்கும் போது, ​​அனைத்து வெளிப்புற அமைப்புகளுக்கான இணைப்பிகளை - 1C, விளம்பர தளங்கள் மற்றும் விளம்பர அமைப்புகள் - தனி சேவைகளாக பிரித்தோம்.
முக்கிய யோசனை என்னவென்றால், தளங்களுக்கான அனைத்து இணைப்பிகளும் ஒரே API ஐக் கொண்டுள்ளன, மேலும் அவை தள API ஐ நமக்கு வசதியான இடைமுகத்திற்குக் கொண்டுவரும் அடாப்டர்களாகும்.

எங்கள் தயாரிப்பின் மையத்தில் ஒரு இணையப் பயன்பாடு உள்ளது, இது ஒரு மோனோலித் ஆகும், இது சேவைகளில் எளிதாகப் பிரிக்கக்கூடிய வகையில் வடிவமைக்கப்பட்டுள்ளது. பதிவிறக்கம் செய்யப்பட்ட தரவைச் செயலாக்குவதற்கும், வெவ்வேறு கணினிகளிலிருந்து புள்ளிவிவரங்களைத் தொகுப்பதற்கும், அவற்றை கணினி பயனர்களுக்கு வழங்குவதற்கும் இந்தப் பயன்பாடு பொறுப்பாகும்.

இணைப்பிகள் மற்றும் இணையப் பயன்பாட்டிற்கு இடையே தொடர்பு கொள்ள, நாங்கள் ஒரு கூடுதல் சேவையை உருவாக்க வேண்டும், அதை நாங்கள் Connector Proxy என்று அழைத்தோம். இது சர்வீஸ் டிஸ்கவரி மற்றும் டாஸ்க் ஷெட்யூலரின் செயல்பாடுகளை செய்கிறது. இந்த சேவை ஒவ்வொரு இரவும் ஒவ்வொரு இணைப்பிற்கும் தரவு சேகரிப்பு பணிகளை இயக்குகிறது. ஒரு செய்தி தரகரை இணைப்பதை விட சேவை அடுக்கை எழுதுவது எளிதானது, மேலும் முடிந்தவரை விரைவாக முடிவைப் பெறுவது எங்களுக்கு முக்கியமானது.

எளிமை மற்றும் வளர்ச்சியின் வேகத்திற்காக, அனைத்து சேவைகளும் Web APIகளாக இருக்கும் என்றும் முடிவு செய்தோம். இது ஒரு கருத்துருவின் ஆதாரத்தை விரைவாகச் சேகரித்து முழு வடிவமைப்பும் செயல்படுகிறதா என்பதைச் சரிபார்க்க முடிந்தது.

வெவ்வேறு கணக்குகளிலிருந்து தரவைச் சேகரிப்பதற்கான அணுகலை அமைப்பது ஒரு தனி, மாறாக சிக்கலான பணியாகும், இது நாங்கள் முடிவு செய்தபடி, இணைய இடைமுகம் மூலம் பயனர்களால் மேற்கொள்ளப்பட வேண்டும். இது இரண்டு தனித்தனி படிகளைக் கொண்டுள்ளது: முதலில், OAuth வழியாக கணக்கை அணுக பயனர் ஒரு டோக்கனைச் சேர்க்கிறார், பின்னர் ஒரு குறிப்பிட்ட கணக்கிலிருந்து கிளையண்டிற்கான தரவு சேகரிப்பை உள்ளமைக்கிறார். OAuth வழியாக ஒரு டோக்கனைப் பெறுவது அவசியம், ஏனென்றால், நாங்கள் ஏற்கனவே எழுதியது போல, தளத்தில் விரும்பிய கணக்கிற்கான அணுகலை வழங்குவது எப்போதும் சாத்தியமில்லை.

தளங்களில் இருந்து கணக்கைத் தேர்ந்தெடுப்பதற்கான உலகளாவிய பொறிமுறையை உருவாக்க, JSON ஸ்கீமாவை வழங்கும் இணைப்பிகள் API இல் ஒரு முறையைச் சேர்க்க வேண்டும், இது மாற்றியமைக்கப்பட்ட JSONEditor கூறுகளைப் பயன்படுத்தி ஒரு படிவத்தில் தரப்படுகிறது. இந்த வழியில், பயனர்கள் தரவைப் பதிவிறக்க வேண்டிய கணக்குகளைத் தேர்ந்தெடுக்க முடிந்தது.

தளங்களில் இருக்கும் கோரிக்கை வரம்புகளுக்கு இணங்க, அமைப்புகளுக்கான கோரிக்கைகளை ஒரு டோக்கனுக்குள் இணைக்கிறோம், ஆனால் வெவ்வேறு டோக்கன்களை இணையாகச் செயல்படுத்தலாம்.

வலை பயன்பாடு மற்றும் இணைப்பிகள் ஆகிய இரண்டிற்கும் ஏற்றப்பட்ட தரவுகளுக்கான சேமிப்பகமாக MongoDB ஐத் தேர்ந்தெடுத்தோம், இது ஒவ்வொரு நாளும் பயன்பாட்டின் ஆப்ஜெக்ட் மாதிரி மாறும் போது, ​​வளர்ச்சியின் ஆரம்ப கட்டங்களில் தரவு கட்டமைப்பைப் பற்றி அதிகம் கவலைப்படாமல் இருக்க அனுமதித்தது.

மொங்கோடிபியில் எல்லாத் தரவும் சரியாகப் பொருந்தவில்லை என்பதை விரைவில் கண்டறிந்தோம், உதாரணமாக, தினசரி புள்ளிவிவரங்களை தொடர்புடைய தரவுத்தளத்தில் சேமிப்பது மிகவும் வசதியானது. எனவே, தொடர்புடைய தரவுத்தளத்திற்கு மிகவும் பொருத்தமான தரவுக் கட்டமைப்பைக் கொண்ட இணைப்பாளர்களுக்கு, PostgreSQL அல்லது MS SQL சேவையகத்தை சேமிப்பகமாகப் பயன்படுத்தத் தொடங்கினோம்.

தேர்ந்தெடுக்கப்பட்ட கட்டிடக்கலை மற்றும் தொழில்நுட்பங்கள், ஒப்பீட்டளவில் விரைவாக D1.Digital தயாரிப்பை உருவாக்கவும் தொடங்கவும் எங்களை அனுமதித்தன. தயாரிப்பு மேம்பாட்டின் இரண்டு ஆண்டுகளில், நாங்கள் தளங்களுக்கான 23 இணைப்பிகளை உருவாக்கினோம், மூன்றாம் தரப்பு API களுடன் பணிபுரியும் விலைமதிப்பற்ற அனுபவத்தைப் பெற்றோம், வெவ்வேறு தளங்களின் ஆபத்துக்களைத் தவிர்க்க கற்றுக்கொண்டோம், ஒவ்வொன்றும் அவற்றின் சொந்தமாக இருந்தது, குறைந்தது 3 API இன் வளர்ச்சிக்கு பங்களித்தது. தளங்கள், கிட்டத்தட்ட 15 பிரச்சாரங்கள் மற்றும் 000 க்கும் மேற்பட்ட இடங்கள் பற்றிய தகவல்களை தானாகவே பதிவிறக்கம் செய்து, தயாரிப்பின் செயல்பாடு குறித்த பயனர்களிடமிருந்து நிறைய கருத்துக்களை சேகரித்து, இந்த பின்னூட்டத்தின் அடிப்படையில் தயாரிப்பின் முக்கிய செயல்முறையை பல முறை மாற்ற முடிந்தது.

தீர்வு கட்டமைப்பு 2.0

வளர்ச்சி தொடங்கி இரண்டு ஆண்டுகள் கடந்துவிட்டன டி 1. டிஜிட்டல். கணினியில் சுமையின் நிலையான அதிகரிப்பு மற்றும் மேலும் மேலும் புதிய தரவு மூலங்களின் தோற்றம், தற்போதுள்ள தீர்வு கட்டமைப்பில் உள்ள சிக்கல்களை படிப்படியாக வெளிப்படுத்தியது.

முதல் சிக்கல் தளங்களில் இருந்து பதிவிறக்கம் செய்யப்பட்ட தரவு அளவு தொடர்பானது. மிகப்பெரிய தளங்களிலிருந்து தேவையான அனைத்து தரவையும் சேகரித்து புதுப்பிக்க அதிக நேரம் எடுக்கத் தொடங்கியது என்ற உண்மையை நாங்கள் எதிர்கொண்டோம். எடுத்துக்காட்டாக, AdRiver விளம்பர அமைப்பிலிருந்து தரவைச் சேகரிப்பது, பெரும்பாலான இடங்களுக்கான புள்ளிவிவரங்களை நாங்கள் கண்காணிக்கும், சுமார் 12 மணிநேரம் ஆகும்.

இந்தச் சிக்கலைத் தீர்க்க, தளங்களிலிருந்து தரவைப் பதிவிறக்க அனைத்து வகையான அறிக்கைகளையும் பயன்படுத்தத் தொடங்கினோம், அவற்றின் செயல்பாட்டின் வேகம் எங்கள் தேவைகளைப் பூர்த்தி செய்யும் வகையில் தளங்களுடன் இணைந்து அவற்றின் API ஐ உருவாக்க முயற்சிக்கிறோம், மேலும் தரவு பதிவிறக்கத்தை முடிந்தவரை இணையாக மாற்றுகிறோம்.

பதிவிறக்கம் செய்யப்பட்ட தரவை செயலாக்குவது தொடர்பான மற்றொரு சிக்கல். இப்போது, ​​புதிய வேலை வாய்ப்பு புள்ளி விவரங்கள் வரும்போது, ​​பல கட்ட அளவீடுகள் மீண்டும் கணக்கிடும் செயல்முறை தொடங்கப்படுகிறது, இதில் மூலத் தரவை ஏற்றுதல், ஒவ்வொரு தளத்திற்கும் ஒருங்கிணைக்கப்பட்ட அளவீடுகளைக் கணக்கிடுதல், வெவ்வேறு மூலங்களிலிருந்து தரவை ஒன்றோடொன்று ஒப்பிடுதல் மற்றும் பிரச்சாரத்திற்கான சுருக்க அளவீடுகளைக் கணக்கிடுதல் ஆகியவை அடங்கும். இது அனைத்து கணக்கீடுகளையும் செய்யும் இணைய பயன்பாட்டில் அதிக சுமைகளை ஏற்படுத்துகிறது. பல முறை, மறு கணக்கீடு செயல்பாட்டின் போது, ​​பயன்பாடு சர்வரில் உள்ள அனைத்து நினைவகத்தையும், சுமார் 10-15 ஜிபி வரை உட்கொண்டது, இது கணினியுடன் பயனர்களின் வேலையில் மிகவும் தீங்கு விளைவிக்கும்.

அடையாளம் காணப்பட்ட சிக்கல்கள் மற்றும் தயாரிப்பின் மேலும் வளர்ச்சிக்கான லட்சியத் திட்டங்கள் பயன்பாட்டு கட்டமைப்பை மறுபரிசீலனை செய்ய வேண்டிய அவசியத்திற்கு எங்களை இட்டுச் சென்றது.

நாங்கள் இணைப்பிகளுடன் தொடங்கினோம்.
எல்லா இணைப்பிகளும் ஒரே மாதிரியின் படி செயல்படுவதை நாங்கள் கவனித்தோம், எனவே ஒரு இணைப்பியை உருவாக்க ஒரு பைப்லைன் கட்டமைப்பை நாங்கள் உருவாக்கியுள்ளோம், அதில் நீங்கள் படிகளின் தர்க்கத்தை மட்டுமே நிரல் செய்ய வேண்டும், மீதமுள்ளவை உலகளாவியவை. ஒரு இணைப்பிக்கு முன்னேற்றம் தேவைப்பட்டால், இணைப்பான் மேம்படுத்தப்படும் அதே நேரத்தில் அதை உடனடியாக ஒரு புதிய கட்டமைப்பிற்கு மாற்றுவோம்.

அதே நேரத்தில், நாங்கள் டோக்கர் மற்றும் குபெர்னெட்டஸுக்கு இணைப்பான்களைப் பயன்படுத்தத் தொடங்கினோம்.
குபெர்னெட்டஸுக்குச் செல்ல நாங்கள் நீண்ட காலமாகத் திட்டமிட்டோம், சிஐ/சிடி அமைப்புகளைப் பரிசோதித்தோம், ஆனால் ஒரு இணைப்பான், ஒரு பிழையின் காரணமாக, சர்வரில் 20 ஜிபிக்கும் அதிகமான நினைவகத்தை உண்ணத் தொடங்கியது, நடைமுறையில் மற்ற செயல்முறைகளை அழிக்கத் தொடங்கியது. . விசாரணையின் போது, ​​கனெக்டர் ஒரு குபெர்னெட்டஸ் கிளஸ்டருக்கு மாற்றப்பட்டது, பிழை சரி செய்யப்பட்ட பிறகும் அது இறுதியில் இருந்தது.

குபெர்னெட்ஸ் வசதியானது என்பதை நாங்கள் மிக விரைவாக உணர்ந்தோம், மேலும் ஆறு மாதங்களுக்குள் 7 இணைப்பிகள் மற்றும் அதிக வளங்களைப் பயன்படுத்தும் இணைப்பிகள் ப்ராக்ஸியை உற்பத்தி கிளஸ்டருக்கு மாற்றினோம்.

இணைப்பிகளைப் பின்பற்றி, மீதமுள்ள பயன்பாட்டின் கட்டமைப்பை மாற்ற முடிவு செய்தோம்.
முக்கிய பிரச்சனை என்னவென்றால், பெரிய தொகுதிகளில் உள்ள இணைப்பிகளிலிருந்து ப்ராக்ஸிகளுக்கு தரவு வருகிறது, பின்னர் DANBoID ஐத் தாக்கி, செயலாக்கத்திற்கான மைய வலைப் பயன்பாட்டிற்கு அனுப்பப்படும். அதிக எண்ணிக்கையிலான அளவீடுகள் மறுகணக்கீடுகள் காரணமாக, பயன்பாட்டில் அதிக சுமை உள்ளது.

தனிப்பட்ட தரவு சேகரிப்பு வேலைகளின் நிலையை கண்காணிப்பதும், மைய வலை பயன்பாட்டிற்கான இணைப்பிகளுக்குள் நிகழும் பிழைகளைப் புகாரளிப்பதும் மிகவும் கடினமாக இருந்தது, இதனால் பயனர்கள் என்ன நடக்கிறது மற்றும் ஏன் தரவு சேகரிக்கப்படவில்லை என்பதைக் காணலாம்.

இந்த சிக்கல்களை தீர்க்க, நாங்கள் கட்டிடக்கலை 2.0 ஐ உருவாக்கினோம்.

கட்டிடக்கலையின் புதிய பதிப்பிற்கு இடையே உள்ள முக்கிய வேறுபாடு என்னவென்றால், Web API க்கு பதிலாக, RabbitMQ மற்றும் MassTransit நூலகத்தைப் பயன்படுத்தி சேவைகளுக்கு இடையே செய்திகளைப் பரிமாறிக் கொள்கிறோம். இதைச் செய்ய, கனெக்டர்ஸ் ப்ராக்ஸியை நாங்கள் முழுமையாக மீண்டும் எழுத வேண்டியிருந்தது, இது கனெக்டர்ஸ் ஹப் ஆகும். பெயர் மாற்றப்பட்டது, ஏனெனில் சேவையின் முக்கியப் பணியானது இணைப்பாளர்களுக்கு கோரிக்கைகளை அனுப்புவதில் இல்லை, ஆனால் இணைப்பான்களிடமிருந்து அளவீடுகளின் சேகரிப்பை நிர்வகிப்பதில் உள்ளது.

மைய வலைப் பயன்பாட்டிலிருந்து, தளங்களிலிருந்து இடங்கள் மற்றும் புள்ளிவிவரங்கள் பற்றிய தகவல்களைத் தனித்தனி சேவைகளாகப் பிரித்தோம், இது தேவையற்ற மறு கணக்கீடுகளிலிருந்து விடுபடவும், ஏற்கனவே கணக்கிடப்பட்ட மற்றும் திரட்டப்பட்ட புள்ளிவிவரங்களை மட்டுமே வேலை வாய்ப்பு மட்டத்தில் சேமிக்கவும் முடிந்தது. மூலத் தரவின் அடிப்படையில் அடிப்படைப் புள்ளிவிவரங்களைக் கணக்கிடுவதற்கான லாஜிக்கை மீண்டும் எழுதி மேம்படுத்தியுள்ளோம்.

அதே நேரத்தில், தீர்வை அளவிடுவதை எளிதாக்கவும், நிர்வகிக்க மிகவும் வசதியாகவும் எல்லா சேவைகளையும் பயன்பாடுகளையும் Docker மற்றும் Kubernetes க்கு மாற்றுகிறோம்.

நாம் இப்போது எங்கே இருக்கிறோம்

ப்ரூஃப்-ஆஃப்-கான்செப்ட் ஆர்கிடெக்சர் 2.0 தயாரிப்பு டி 1. டிஜிட்டல் ஒரு வரையறுக்கப்பட்ட இணைப்பிகளுடன் சோதனை சூழலில் தயாராக மற்றும் வேலை செய்கிறது. இன்னும் 20 கனெக்டர்களை புதிய இயங்குதளத்திற்கு மாற்றி எழுதுவது, தரவு சரியாக ஏற்றப்பட்டுள்ளதா மற்றும் அனைத்து அளவீடுகளும் சரியாகக் கணக்கிடப்பட்டுள்ளனவா என்பதைச் சோதித்து, முழு வடிவமைப்பையும் தயாரிப்பில் மாற்றுவது மட்டுமே மீதமுள்ளது.

உண்மையில், இந்த செயல்முறை படிப்படியாக நடக்கும், மேலும் எல்லாவற்றையும் செயல்பட வைக்க பழைய APIகளுடன் பின்தங்கிய இணக்கத்தன்மையை விட்டுவிட வேண்டும்.

எங்களின் உடனடித் திட்டங்களில் புதிய இணைப்பிகளை உருவாக்குதல், புதிய அமைப்புகளுடன் ஒருங்கிணைத்தல் மற்றும் இணைக்கப்பட்ட தளங்கள் மற்றும் விளம்பர அமைப்புகளிலிருந்து பதிவிறக்கம் செய்யப்பட்ட தரவுகளின் தொகுப்பில் கூடுதல் அளவீடுகளைச் சேர்ப்பது ஆகியவை அடங்கும்.

மத்திய இணைய பயன்பாடு உட்பட அனைத்து பயன்பாடுகளையும் டோக்கர் மற்றும் குபெர்னெட்டஸுக்கு மாற்றவும் திட்டமிட்டுள்ளோம். புதிய கட்டிடக்கலையுடன் இணைந்து, இது நுகரப்படும் வளங்களின் வரிசைப்படுத்தல், கண்காணிப்பு மற்றும் கட்டுப்பாட்டை கணிசமாக எளிதாக்கும்.

மற்றொரு யோசனை, தற்போது MongoDB இல் சேமிக்கப்பட்டுள்ள புள்ளிவிவரங்களை சேமிப்பதற்கான தரவுத்தளத்தின் தேர்வை பரிசோதிப்பது. நாங்கள் ஏற்கனவே பல புதிய இணைப்பிகளை SQL தரவுத்தளங்களுக்கு மாற்றியுள்ளோம், ஆனால் அங்கு வித்தியாசம் கிட்டத்தட்ட கவனிக்க முடியாதது, மேலும் ஒரு தன்னிச்சையான காலத்திற்குக் கோரப்படும் நாளின் ஒருங்கிணைந்த புள்ளிவிவரங்களுக்கு, ஆதாயம் மிகவும் தீவிரமாக இருக்கும்.

பொதுவாக, திட்டங்கள் பிரமாண்டமானவை, தொடரலாம் :)

கட்டுரையின் ஆசிரியர்கள் R&D Dentsu Aegis Network Russia: Georgy Ostapenko (ஷ்மிகா), மிகைல் கோட்சிக் (ஹிடெக்ஸ்)

ஆதாரம்: www.habr.com