ಆನ್‌ಲೈನ್ ಸೈಟ್‌ಗಳಿಂದ ನಾವು ಜಾಹೀರಾತು ಪ್ರಚಾರಗಳ ಡೇಟಾವನ್ನು ಹೇಗೆ ಸಂಗ್ರಹಿಸಿದ್ದೇವೆ (ಉತ್ಪನ್ನಕ್ಕೆ ಮುಳ್ಳಿನ ಹಾದಿ)

ಆನ್‌ಲೈನ್ ಜಾಹೀರಾತಿನ ಕ್ಷೇತ್ರವು ಸಾಧ್ಯವಾದಷ್ಟು ತಾಂತ್ರಿಕವಾಗಿ ಮುಂದುವರಿದ ಮತ್ತು ಸ್ವಯಂಚಾಲಿತವಾಗಿರಬೇಕು ಎಂದು ತೋರುತ್ತದೆ. ಸಹಜವಾಗಿ, Yandex, Mail.Ru, Google ಮತ್ತು Facebook ನಂತಹ ಅವರ ಕ್ಷೇತ್ರದಲ್ಲಿ ಅಂತಹ ದೈತ್ಯರು ಮತ್ತು ತಜ್ಞರು ಅಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ. ಆದರೆ, ಅದು ಬದಲಾದಂತೆ, ಪರಿಪೂರ್ಣತೆಗೆ ಯಾವುದೇ ಮಿತಿಯಿಲ್ಲ ಮತ್ತು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ಯಾವಾಗಲೂ ಏನಾದರೂ ಇರುತ್ತದೆ.

ಮೂಲ

ಸಂವಹನ ಗುಂಪು ಡೆಂಟ್ಸು ಏಜಿಸ್ ನೆಟ್ವರ್ಕ್ ರಷ್ಯಾ ಡಿಜಿಟಲ್ ಜಾಹೀರಾತು ಮಾರುಕಟ್ಟೆಯಲ್ಲಿ ಅತಿದೊಡ್ಡ ಆಟಗಾರ ಮತ್ತು ತಂತ್ರಜ್ಞಾನದಲ್ಲಿ ಸಕ್ರಿಯವಾಗಿ ಹೂಡಿಕೆ ಮಾಡುತ್ತಿದೆ, ಅದರ ವ್ಯವಹಾರ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಅತ್ಯುತ್ತಮವಾಗಿಸಲು ಮತ್ತು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದೆ. ಆನ್‌ಲೈನ್ ಜಾಹೀರಾತು ಮಾರುಕಟ್ಟೆಯ ಬಗೆಹರಿಯದ ಸಮಸ್ಯೆಗಳಲ್ಲಿ ಒಂದಾದ ವಿವಿಧ ಇಂಟರ್ನೆಟ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಿಂದ ಜಾಹೀರಾತು ಪ್ರಚಾರಗಳ ಅಂಕಿಅಂಶಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಕಾರ್ಯವಾಗಿದೆ. ಈ ಸಮಸ್ಯೆಗೆ ಪರಿಹಾರವು ಅಂತಿಮವಾಗಿ ಉತ್ಪನ್ನದ ಸೃಷ್ಟಿಗೆ ಕಾರಣವಾಯಿತು D1.ಡಿಜಿಟಲ್ (ದಿವಾನ್ ಎಂದು ಓದಿ), ಅದರ ಅಭಿವೃದ್ಧಿಯ ಬಗ್ಗೆ ನಾವು ಮಾತನಾಡಲು ಬಯಸುತ್ತೇವೆ.

ಯಾಕೆ?

1. ಯೋಜನೆಯ ಪ್ರಾರಂಭದ ಸಮಯದಲ್ಲಿ, ಜಾಹೀರಾತು ಪ್ರಚಾರಗಳ ಅಂಕಿಅಂಶಗಳ ಸಂಗ್ರಹವನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವ ಒಂದೇ ಒಂದು ಸಿದ್ಧ ಉತ್ಪನ್ನವು ಮಾರುಕಟ್ಟೆಯಲ್ಲಿ ಇರಲಿಲ್ಲ. ಇದರರ್ಥ ನಮ್ಮನ್ನು ಹೊರತುಪಡಿಸಿ ಯಾರೂ ನಮ್ಮ ಅಗತ್ಯಗಳನ್ನು ಪೂರೈಸುವುದಿಲ್ಲ.

Improvado, Roistat, Supermetrics, SegmentStream ನಂತಹ ಸೇವೆಗಳು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳು, ಸಾಮಾಜಿಕ ನೆಟ್‌ವರ್ಕ್‌ಗಳು ಮತ್ತು Google Analytics ನೊಂದಿಗೆ ಏಕೀಕರಣವನ್ನು ನೀಡುತ್ತವೆ ಮತ್ತು ಅನುಕೂಲಕರ ವಿಶ್ಲೇಷಣೆ ಮತ್ತು ಜಾಹೀರಾತು ಪ್ರಚಾರಗಳ ನಿಯಂತ್ರಣಕ್ಕಾಗಿ ವಿಶ್ಲೇಷಣಾತ್ಮಕ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ. ನಾವು ನಮ್ಮ ಉತ್ಪನ್ನವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು, ಸೈಟ್‌ಗಳಿಂದ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ನಾವು ಈ ಕೆಲವು ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ಬಳಸಲು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ, ಆದರೆ, ದುರದೃಷ್ಟವಶಾತ್, ಅವರು ನಮ್ಮ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ.

ಮುಖ್ಯ ಸಮಸ್ಯೆಯೆಂದರೆ, ಪರೀಕ್ಷಿತ ಉತ್ಪನ್ನಗಳು ಡೇಟಾ ಮೂಲಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿವೆ, ಸೈಟ್ ಮೂಲಕ ಪ್ಲೇಸ್‌ಮೆಂಟ್ ಅಂಕಿಅಂಶಗಳನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತವೆ ಮತ್ತು ಜಾಹೀರಾತು ಪ್ರಚಾರಗಳಲ್ಲಿ ಅಂಕಿಅಂಶಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಒದಗಿಸಲಿಲ್ಲ. ಈ ವಿಧಾನವು ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ವಿವಿಧ ಸೈಟ್‌ಗಳಿಂದ ಅಂಕಿಅಂಶಗಳನ್ನು ನೋಡಲು ಮತ್ತು ಒಟ್ಟಾರೆಯಾಗಿ ಅಭಿಯಾನದ ಸ್ಥಿತಿಯನ್ನು ವಿಶ್ಲೇಷಿಸಲು ನಮಗೆ ಅನುಮತಿಸಲಿಲ್ಲ.

ಮತ್ತೊಂದು ಅಂಶವೆಂದರೆ ಆರಂಭಿಕ ಹಂತಗಳಲ್ಲಿ ಉತ್ಪನ್ನಗಳು ಪಾಶ್ಚಿಮಾತ್ಯ ಮಾರುಕಟ್ಟೆಯನ್ನು ಗುರಿಯಾಗಿರಿಸಿಕೊಂಡಿವೆ ಮತ್ತು ರಷ್ಯಾದ ಸೈಟ್ಗಳೊಂದಿಗೆ ಏಕೀಕರಣವನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ. ಮತ್ತು ಏಕೀಕರಣವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದ ಸೈಟ್‌ಗಳಿಗೆ, ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಯಾವಾಗಲೂ ಸಾಕಷ್ಟು ವಿವರಗಳೊಂದಿಗೆ ಡೌನ್‌ಲೋಡ್ ಮಾಡಲಾಗಿಲ್ಲ, ಮತ್ತು ಏಕೀಕರಣವು ಯಾವಾಗಲೂ ಅನುಕೂಲಕರ ಮತ್ತು ಪಾರದರ್ಶಕವಾಗಿರುವುದಿಲ್ಲ, ವಿಶೇಷವಾಗಿ ಸಿಸ್ಟಮ್ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿಲ್ಲದದನ್ನು ಪಡೆಯಲು ಅಗತ್ಯವಾದಾಗ.
ಸಾಮಾನ್ಯವಾಗಿ, ನಾವು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಉತ್ಪನ್ನಗಳಿಗೆ ಹೊಂದಿಕೊಳ್ಳದಿರಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ, ಆದರೆ ನಮ್ಮದೇ ಆದ ಅಭಿವೃದ್ಧಿಯನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ...

2. ಆನ್‌ಲೈನ್ ಜಾಹೀರಾತು ಮಾರುಕಟ್ಟೆಯು ವರ್ಷದಿಂದ ವರ್ಷಕ್ಕೆ ಬೆಳೆಯುತ್ತಿದೆ ಮತ್ತು 2018 ರಲ್ಲಿ, ಜಾಹೀರಾತು ಬಜೆಟ್‌ಗಳ ವಿಷಯದಲ್ಲಿ, ಇದು ಸಾಂಪ್ರದಾಯಿಕವಾಗಿ ಅತಿದೊಡ್ಡ ಟಿವಿ ಜಾಹೀರಾತು ಮಾರುಕಟ್ಟೆಯನ್ನು ಹಿಂದಿಕ್ಕಿದೆ. ಆದ್ದರಿಂದ ಒಂದು ಪ್ರಮಾಣವಿದೆ.

3. ಟಿವಿ ಜಾಹೀರಾತು ಮಾರುಕಟ್ಟೆಗಿಂತ ಭಿನ್ನವಾಗಿ, ವಾಣಿಜ್ಯ ಜಾಹೀರಾತಿನ ಮಾರಾಟವು ಏಕಸ್ವಾಮ್ಯವನ್ನು ಹೊಂದಿದೆ, ತಮ್ಮದೇ ಆದ ಜಾಹೀರಾತು ಖಾತೆಗಳೊಂದಿಗೆ ಅಂತರ್ಜಾಲದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ವಿವಿಧ ಗಾತ್ರಗಳ ಜಾಹೀರಾತು ದಾಸ್ತಾನುಗಳ ಬಹಳಷ್ಟು ವೈಯಕ್ತಿಕ ಮಾಲೀಕರು ಇದ್ದಾರೆ. ಜಾಹೀರಾತು ಪ್ರಚಾರವು ನಿಯಮದಂತೆ, ಹಲವಾರು ಸೈಟ್‌ಗಳಲ್ಲಿ ಏಕಕಾಲದಲ್ಲಿ ಚಲಿಸುವುದರಿಂದ, ಜಾಹೀರಾತು ಪ್ರಚಾರದ ಸ್ಥಿತಿಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ಎಲ್ಲಾ ಸೈಟ್‌ಗಳಿಂದ ವರದಿಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದು ಮತ್ತು ಅವುಗಳನ್ನು ಸಂಪೂರ್ಣ ಚಿತ್ರವನ್ನು ತೋರಿಸುವ ಒಂದು ದೊಡ್ಡ ವರದಿಯಾಗಿ ಸಂಯೋಜಿಸುವುದು ಅವಶ್ಯಕ. ಇದರರ್ಥ ಆಪ್ಟಿಮೈಸೇಶನ್ ಸಾಮರ್ಥ್ಯವಿದೆ.

4. ಅಂತರ್ಜಾಲದಲ್ಲಿ ಜಾಹೀರಾತು ದಾಸ್ತಾನು ಮಾಲೀಕರು ಈಗಾಗಲೇ ಅಂಕಿಅಂಶಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಮತ್ತು ಜಾಹೀರಾತು ಖಾತೆಗಳಲ್ಲಿ ಅವುಗಳನ್ನು ಪ್ರದರ್ಶಿಸಲು ಮೂಲಸೌಕರ್ಯವನ್ನು ಹೊಂದಿದ್ದಾರೆ ಮತ್ತು ಅವರು ಈ ಡೇಟಾಕ್ಕಾಗಿ API ಅನ್ನು ಒದಗಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಎಂದು ನಮಗೆ ತೋರುತ್ತದೆ. ಇದರರ್ಥ ತಾಂತ್ರಿಕವಾಗಿ ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸಾಧ್ಯವಿದೆ. ಅದು ಅಷ್ಟು ಸುಲಭವಲ್ಲ ಎಂದು ಈಗಿನಿಂದಲೇ ಹೇಳೋಣ.

ಸಾಮಾನ್ಯವಾಗಿ, ಯೋಜನೆಯ ಅನುಷ್ಠಾನಕ್ಕೆ ಎಲ್ಲಾ ಪೂರ್ವಾಪೇಕ್ಷಿತಗಳು ನಮಗೆ ಸ್ಪಷ್ಟವಾಗಿವೆ, ಮತ್ತು ನಾವು ಯೋಜನೆಯನ್ನು ಜೀವಂತಗೊಳಿಸಲು ಓಡಿದೆವು ...

ಬೃಹತ್ ಯೋಜನೆ

ಮೊದಲಿಗೆ, ನಾವು ಆದರ್ಶ ವ್ಯವಸ್ಥೆಯ ದೃಷ್ಟಿಯನ್ನು ರೂಪಿಸಿದ್ದೇವೆ:

• 1C ಕಾರ್ಪೊರೇಟ್ ವ್ಯವಸ್ಥೆಯಿಂದ ಜಾಹೀರಾತು ಪ್ರಚಾರಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಅದರ ಹೆಸರುಗಳು, ಅವಧಿಗಳು, ಬಜೆಟ್‌ಗಳು ಮತ್ತು ವಿವಿಧ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಲ್ಲಿ ನಿಯೋಜನೆಗಳೊಂದಿಗೆ ಲೋಡ್ ಮಾಡಬೇಕು.
• ಜಾಹೀರಾತು ಪ್ರಚಾರದೊಳಗೆ ಪ್ರತಿ ನಿಯೋಜನೆಗಾಗಿ, ಎಲ್ಲಾ ಸಂಭಾವ್ಯ ಅಂಕಿಅಂಶಗಳನ್ನು ಪ್ಲೇಸ್‌ಮೆಂಟ್ ನಡೆಯುತ್ತಿರುವ ಸೈಟ್‌ಗಳಿಂದ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಡೌನ್‌ಲೋಡ್ ಮಾಡಬೇಕು, ಇಂಪ್ರೆಶನ್‌ಗಳ ಸಂಖ್ಯೆ, ಕ್ಲಿಕ್‌ಗಳು, ವೀಕ್ಷಣೆಗಳು ಇತ್ಯಾದಿ.
• Adriver, Weborama, DCM, ಇತ್ಯಾದಿಗಳಂತಹ ಜಾಹೀರಾತು ವ್ಯವಸ್ಥೆಗಳ ಮೂಲಕ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಕೆಲವು ಜಾಹೀರಾತು ಪ್ರಚಾರಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲಾಗುತ್ತದೆ. ರಷ್ಯಾದಲ್ಲಿ ಕೈಗಾರಿಕಾ ಇಂಟರ್ನೆಟ್ ಮೀಟರ್ ಕೂಡ ಇದೆ - ಮೀಡಿಯಾಸ್ಕೋಪ್ ಕಂಪನಿ. ನಮ್ಮ ಯೋಜನೆಯ ಪ್ರಕಾರ, ಸ್ವತಂತ್ರ ಮತ್ತು ಕೈಗಾರಿಕಾ ಮೇಲ್ವಿಚಾರಣೆಯಿಂದ ಡೇಟಾವನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಅನುಗುಣವಾದ ಜಾಹೀರಾತು ಪ್ರಚಾರಗಳಲ್ಲಿ ಲೋಡ್ ಮಾಡಬೇಕು.
• ಇಂಟರ್ನೆಟ್‌ನಲ್ಲಿನ ಹೆಚ್ಚಿನ ಜಾಹೀರಾತು ಪ್ರಚಾರಗಳು ಕೆಲವು ಗುರಿ ಕ್ರಮಗಳನ್ನು (ಖರೀದಿ, ಕರೆ, ಟೆಸ್ಟ್ ಡ್ರೈವ್‌ಗೆ ಸೈನ್ ಅಪ್, ಇತ್ಯಾದಿ) ಗುರಿಯಾಗಿರಿಸಿಕೊಂಡಿವೆ, ಇವುಗಳನ್ನು Google Analytics ಬಳಸಿ ಟ್ರ್ಯಾಕ್ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಪ್ರಚಾರದ ಸ್ಥಿತಿಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಮತ್ತು ಅಂಕಿಅಂಶಗಳು ಸಹ ಮುಖ್ಯವಾಗಿದೆ. ನಮ್ಮ ಉಪಕರಣಕ್ಕೆ ಲೋಡ್ ಮಾಡಬೇಕು.

ಮೊದಲ ಪ್ಯಾನ್ಕೇಕ್ ಮುದ್ದೆಯಾಗಿದೆ

ಸಾಫ್ಟ್‌ವೇರ್ ಅಭಿವೃದ್ಧಿಯ ಹೊಂದಿಕೊಳ್ಳುವ ತತ್ವಗಳಿಗೆ ನಮ್ಮ ಬದ್ಧತೆಯನ್ನು ನೀಡಲಾಗಿದೆ (ಅಗೈಲ್, ಎಲ್ಲಾ ವಿಷಯಗಳು), ನಾವು ಮೊದಲು MVP ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ ಮತ್ತು ನಂತರ ಪುನರಾವರ್ತಿತವಾಗಿ ಉದ್ದೇಶಿತ ಗುರಿಯತ್ತ ಸಾಗುತ್ತೇವೆ.
ನಮ್ಮ ಉತ್ಪನ್ನದ ಆಧಾರದ ಮೇಲೆ MVP ಅನ್ನು ನಿರ್ಮಿಸಲು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ DANBo (ಡೆಂಟ್ಸು ಏಜಿಸ್ ನೆಟ್‌ವರ್ಕ್ ಬೋರ್ಡ್), ಇದು ನಮ್ಮ ಗ್ರಾಹಕರ ಜಾಹೀರಾತು ಪ್ರಚಾರಗಳ ಸಾಮಾನ್ಯ ಮಾಹಿತಿಯೊಂದಿಗೆ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ ಆಗಿದೆ.

MVP ಗಾಗಿ, ಯೋಜನೆಯನ್ನು ಅನುಷ್ಠಾನದ ವಿಷಯದಲ್ಲಿ ಸಾಧ್ಯವಾದಷ್ಟು ಸರಳಗೊಳಿಸಲಾಗಿದೆ. ಏಕೀಕರಣಕ್ಕಾಗಿ ನಾವು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳ ಸೀಮಿತ ಪಟ್ಟಿಯನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ್ದೇವೆ. ಇವುಗಳು Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB, ಮತ್ತು ಮುಖ್ಯ ಜಾಹೀರಾತು ವ್ಯವಸ್ಥೆಗಳಾದ Adriver ಮತ್ತು Weborama ನಂತಹ ಮುಖ್ಯ ವೇದಿಕೆಗಳಾಗಿವೆ.

API ಮೂಲಕ ಸೈಟ್‌ಗಳಲ್ಲಿನ ಅಂಕಿಅಂಶಗಳನ್ನು ಪ್ರವೇಶಿಸಲು, ನಾವು ಒಂದೇ ಖಾತೆಯನ್ನು ಬಳಸಿದ್ದೇವೆ. ಜಾಹೀರಾತು ಪ್ರಚಾರದಲ್ಲಿ ಅಂಕಿಅಂಶಗಳ ಸ್ವಯಂಚಾಲಿತ ಸಂಗ್ರಹವನ್ನು ಬಳಸಲು ಬಯಸಿದ ಕ್ಲೈಂಟ್ ಗ್ರೂಪ್ ಮ್ಯಾನೇಜರ್ ಮೊದಲು ಸೈಟ್‌ಗಳಲ್ಲಿನ ಅಗತ್ಯ ಜಾಹೀರಾತು ಪ್ರಚಾರಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಖಾತೆಗೆ ನಿಯೋಜಿಸಬೇಕಾಗಿತ್ತು.

ಮುಂದಿನದು ಸಿಸ್ಟಮ್ ಬಳಕೆದಾರ DANBo ಒಂದು ನಿರ್ದಿಷ್ಟ ಸ್ವರೂಪದ ಫೈಲ್ ಅನ್ನು ಎಕ್ಸೆಲ್ ಸಿಸ್ಟಮ್‌ಗೆ ಅಪ್‌ಲೋಡ್ ಮಾಡಬೇಕಾಗಿತ್ತು, ಇದರಲ್ಲಿ ಪ್ಲೇಸ್‌ಮೆಂಟ್ (ಜಾಹೀರಾತು ಪ್ರಚಾರ, ಪ್ಲಾಟ್‌ಫಾರ್ಮ್, ಫಾರ್ಮ್ಯಾಟ್, ಪ್ಲೇಸ್‌ಮೆಂಟ್ ಅವಧಿ, ಯೋಜಿತ ಸೂಚಕಗಳು, ಬಜೆಟ್, ಇತ್ಯಾದಿ) ಮತ್ತು ಅನುಗುಣವಾದ ಜಾಹೀರಾತು ಪ್ರಚಾರಗಳ ಗುರುತಿಸುವಿಕೆಗಳ ಬಗ್ಗೆ ಎಲ್ಲಾ ಮಾಹಿತಿಯನ್ನು ಒಳಗೊಂಡಿದೆ. ಜಾಹೀರಾತು ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಸೈಟ್‌ಗಳು ಮತ್ತು ಕೌಂಟರ್‌ಗಳು.

ಇದು ಸ್ಪಷ್ಟವಾಗಿ, ಭಯಾನಕವಾಗಿ ಕಾಣುತ್ತದೆ:

ಡೌನ್‌ಲೋಡ್ ಮಾಡಿದ ಡೇಟಾವನ್ನು ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಉಳಿಸಲಾಗಿದೆ, ಮತ್ತು ನಂತರ ಪ್ರತ್ಯೇಕ ಸೇವೆಗಳು ಅವುಗಳಿಂದ ಸೈಟ್‌ಗಳಲ್ಲಿ ಪ್ರಚಾರ ಗುರುತಿಸುವಿಕೆಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತವೆ ಮತ್ತು ಅವುಗಳ ಮೇಲೆ ಅಂಕಿಅಂಶಗಳನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡುತ್ತವೆ.

ಪ್ರತಿ ಸೈಟ್‌ಗೆ, ಪ್ರತ್ಯೇಕ ವಿಂಡೋಸ್ ಸೇವೆಯನ್ನು ಬರೆಯಲಾಗಿದೆ, ಇದು ದಿನಕ್ಕೆ ಒಮ್ಮೆ ಸೈಟ್‌ನ API ನಲ್ಲಿ ಒಂದು ಸೇವಾ ಖಾತೆಯ ಅಡಿಯಲ್ಲಿ ಹೋಗುತ್ತದೆ ಮತ್ತು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಪ್ರಚಾರ ID ಗಳಿಗೆ ಅಂಕಿಅಂಶಗಳನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡುತ್ತದೆ. ಜಾಹೀರಾತು ವ್ಯವಸ್ಥೆಗಳೊಂದಿಗೆ ಅದೇ ವಿಷಯ ಸಂಭವಿಸಿದೆ.

ಡೌನ್‌ಲೋಡ್ ಮಾಡಿದ ಡೇಟಾವನ್ನು ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಸಣ್ಣ ಕಸ್ಟಮ್ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ರೂಪದಲ್ಲಿ ಪ್ರದರ್ಶಿಸಲಾಗುತ್ತದೆ:

ನಮಗೆ ಅನಿರೀಕ್ಷಿತವಾಗಿ, MVP ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿತು ಮತ್ತು ಇಂಟರ್ನೆಟ್‌ನಲ್ಲಿ ಜಾಹೀರಾತು ಪ್ರಚಾರಗಳಲ್ಲಿ ಪ್ರಸ್ತುತ ಅಂಕಿಅಂಶಗಳನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿತು. ನಾವು ಹಲವಾರು ಕ್ಲೈಂಟ್‌ಗಳಲ್ಲಿ ಸಿಸ್ಟಮ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದ್ದೇವೆ, ಆದರೆ ಅಳೆಯಲು ಪ್ರಯತ್ನಿಸುವಾಗ, ನಾವು ಗಂಭೀರ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸಿದ್ದೇವೆ:

• ಸಿಸ್ಟಮ್ಗೆ ಲೋಡ್ ಮಾಡಲು ಡೇಟಾವನ್ನು ಸಿದ್ಧಪಡಿಸುವ ಸಂಕೀರ್ಣತೆ ಮುಖ್ಯ ಸಮಸ್ಯೆಯಾಗಿದೆ. ಅಲ್ಲದೆ, ಲೋಡ್ ಮಾಡುವ ಮೊದಲು ಪ್ಲೇಸ್‌ಮೆಂಟ್ ಡೇಟಾವನ್ನು ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಸ್ಥಿರ ಸ್ವರೂಪಕ್ಕೆ ಪರಿವರ್ತಿಸಬೇಕು. ಡೌನ್‌ಲೋಡ್ ಫೈಲ್‌ನಲ್ಲಿ ವಿವಿಧ ಸೈಟ್‌ಗಳಿಂದ ಅಸ್ತಿತ್ವದ ಗುರುತಿಸುವಿಕೆಗಳನ್ನು ಸೇರಿಸುವುದು ಅಗತ್ಯವಾಗಿತ್ತು. ತಾಂತ್ರಿಕವಾಗಿ ತರಬೇತಿ ಪಡೆಯದ ಬಳಕೆದಾರರಿಗೆ ಸೈಟ್‌ನಲ್ಲಿ ಈ ಗುರುತಿಸುವಿಕೆಗಳನ್ನು ಎಲ್ಲಿ ಕಂಡುಹಿಡಿಯಬೇಕು ಮತ್ತು ಫೈಲ್‌ನಲ್ಲಿ ಎಲ್ಲಿ ನಮೂದಿಸಬೇಕು ಎಂಬುದನ್ನು ವಿವರಿಸಲು ಇದು ತುಂಬಾ ಕಷ್ಟಕರವಾಗಿದೆ ಎಂಬ ಅಂಶವನ್ನು ನಾವು ಎದುರಿಸುತ್ತೇವೆ. ಸೈಟ್‌ಗಳಲ್ಲಿ ಪ್ರಚಾರಗಳನ್ನು ನಡೆಸುತ್ತಿರುವ ಇಲಾಖೆಗಳಲ್ಲಿನ ಉದ್ಯೋಗಿಗಳ ಸಂಖ್ಯೆ ಮತ್ತು ವಹಿವಾಟನ್ನು ಪರಿಗಣಿಸಿ, ಇದು ನಮ್ಮ ಕಡೆಯಿಂದ ಭಾರಿ ಪ್ರಮಾಣದ ಬೆಂಬಲವನ್ನು ಉಂಟುಮಾಡಿತು, ಅದು ನಮಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಸಂತೋಷವಾಗಿರಲಿಲ್ಲ.
• ಇನ್ನೊಂದು ಸಮಸ್ಯೆಯೆಂದರೆ, ಎಲ್ಲಾ ಜಾಹೀರಾತು ವೇದಿಕೆಗಳು ಇತರ ಖಾತೆಗಳಿಗೆ ಜಾಹೀರಾತು ಪ್ರಚಾರಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ನಿಯೋಜಿಸಲು ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಹೊಂದಿಲ್ಲ. ಆದರೆ ನಿಯೋಗದ ಕಾರ್ಯವಿಧಾನವು ಲಭ್ಯವಿದ್ದರೂ ಸಹ, ಎಲ್ಲಾ ಜಾಹೀರಾತುದಾರರು ತಮ್ಮ ಪ್ರಚಾರಗಳಿಗೆ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಖಾತೆಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ನೀಡಲು ಸಿದ್ಧರಿಲ್ಲ.
• ನಮ್ಮ 1C ಅಕೌಂಟಿಂಗ್ ವ್ಯವಸ್ಥೆಗೆ ಅವರು ಈಗಾಗಲೇ ನಮೂದಿಸಿರುವ ಎಲ್ಲಾ ಯೋಜಿತ ಸೂಚಕಗಳು ಮತ್ತು ನಿಯೋಜನೆ ವಿವರಗಳು, ಅವರು ಮರು-ಪ್ರವೇಶಿಸಬೇಕು ಎಂಬ ಅಂಶದಿಂದ ಬಳಕೆದಾರರಲ್ಲಿ ಕೆರಳಿಸಿದ ಕೋಪವು ಒಂದು ಪ್ರಮುಖ ಅಂಶವಾಗಿದೆ. DANBo.

ಪ್ಲೇಸ್‌ಮೆಂಟ್ ಕುರಿತು ಮಾಹಿತಿಯ ಪ್ರಾಥಮಿಕ ಮೂಲವು ನಮ್ಮ 1C ಸಿಸ್ಟಮ್ ಆಗಿರಬೇಕು ಎಂಬ ಕಲ್ಪನೆಯನ್ನು ಇದು ನಮಗೆ ನೀಡಿತು, ಇದರಲ್ಲಿ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ನಿಖರವಾಗಿ ಮತ್ತು ಸಮಯಕ್ಕೆ ನಮೂದಿಸಲಾಗುತ್ತದೆ (ಇಲ್ಲಿನ ಅಂಶವೆಂದರೆ 1C ಡೇಟಾದ ಆಧಾರದ ಮೇಲೆ ಇನ್‌ವಾಯ್ಸ್‌ಗಳನ್ನು ರಚಿಸಲಾಗಿದೆ, ಆದ್ದರಿಂದ 1C ಗೆ ಡೇಟಾವನ್ನು ಸರಿಯಾಗಿ ನಮೂದಿಸಿ ಎಲ್ಲರಿಗೂ ಕೆಪಿಐ) ಆದ್ಯತೆಯಾಗಿದೆ. ವ್ಯವಸ್ಥೆಯ ಹೊಸ ಪರಿಕಲ್ಪನೆ ಹುಟ್ಟಿಕೊಂಡಿದ್ದು ಹೀಗೆ...

ಪರಿಕಲ್ಪನೆ

ಇಂಟರ್ನೆಟ್‌ನಲ್ಲಿ ಜಾಹೀರಾತು ಪ್ರಚಾರಗಳ ಅಂಕಿಅಂಶಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ವ್ಯವಸ್ಥೆಯನ್ನು ಪ್ರತ್ಯೇಕ ಉತ್ಪನ್ನವಾಗಿ ಪ್ರತ್ಯೇಕಿಸಲು ನಾವು ನಿರ್ಧರಿಸಿದ ಮೊದಲನೆಯದು - D1.ಡಿಜಿಟಲ್.

ಹೊಸ ಪರಿಕಲ್ಪನೆಯಲ್ಲಿ, ನಾವು ಲೋಡ್ ಮಾಡಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ D1.ಡಿಜಿಟಲ್ 1C ಯಿಂದ ಅವುಗಳೊಳಗೆ ಜಾಹೀರಾತು ಪ್ರಚಾರಗಳು ಮತ್ತು ನಿಯೋಜನೆಗಳ ಕುರಿತು ಮಾಹಿತಿ, ತದನಂತರ ಈ ನಿಯೋಜನೆಗಳಿಗೆ ಸೈಟ್‌ಗಳು ಮತ್ತು ಆಡ್‌ಸರ್ವಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳಿಂದ ಅಂಕಿಅಂಶಗಳನ್ನು ಎಳೆಯಿರಿ. ಇದು ಬಳಕೆದಾರರ ಜೀವನವನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಸರಳಗೊಳಿಸುತ್ತದೆ (ಮತ್ತು, ಎಂದಿನಂತೆ, ಡೆವಲಪರ್‌ಗಳಿಗೆ ಹೆಚ್ಚಿನ ಕೆಲಸವನ್ನು ಸೇರಿಸಿ) ಮತ್ತು ಬೆಂಬಲದ ಪ್ರಮಾಣವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ನಾವು ಎದುರಿಸಿದ ಮೊದಲ ಸಮಸ್ಯೆಯು ಸಾಂಸ್ಥಿಕ ಸ್ವರೂಪದ್ದಾಗಿದೆ ಮತ್ತು ನಾವು 1C ಯಿಂದ ಪ್ರಚಾರಗಳು ಮತ್ತು ನಿಯೋಜನೆಗಳೊಂದಿಗೆ ವಿವಿಧ ಸಿಸ್ಟಮ್‌ಗಳಿಂದ ಘಟಕಗಳನ್ನು ಹೋಲಿಸಬಹುದಾದ ಕೀ ಅಥವಾ ಚಿಹ್ನೆಯನ್ನು ಕಂಡುಹಿಡಿಯಲಾಗಲಿಲ್ಲ ಎಂಬ ಅಂಶಕ್ಕೆ ಸಂಬಂಧಿಸಿದೆ. ಸತ್ಯವೆಂದರೆ ನಮ್ಮ ಕಂಪನಿಯಲ್ಲಿನ ಪ್ರಕ್ರಿಯೆಯನ್ನು ವಿಭಿನ್ನ ಜನರು (ಮಾಧ್ಯಮ ಯೋಜಕರು, ಖರೀದಿ, ಇತ್ಯಾದಿ) ವಿವಿಧ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಜಾಹೀರಾತು ಪ್ರಚಾರಗಳನ್ನು ಪ್ರವೇಶಿಸುವ ರೀತಿಯಲ್ಲಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ.

ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, ನಾವು ವಿಶಿಷ್ಟವಾದ ಹ್ಯಾಶ್ಡ್ ಕೀ, DANBoID ಅನ್ನು ಆವಿಷ್ಕರಿಸಬೇಕಾಗಿತ್ತು, ಅದು ವಿಭಿನ್ನ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿನ ಘಟಕಗಳನ್ನು ಒಟ್ಟಿಗೆ ಜೋಡಿಸುತ್ತದೆ ಮತ್ತು ಡೌನ್‌ಲೋಡ್ ಮಾಡಿದ ಡೇಟಾ ಸೆಟ್‌ಗಳಲ್ಲಿ ಅದನ್ನು ಸುಲಭವಾಗಿ ಮತ್ತು ಅನನ್ಯವಾಗಿ ಗುರುತಿಸಬಹುದು. ಈ ಐಡೆಂಟಿಫೈಯರ್ ಅನ್ನು ಪ್ರತಿ ಪ್ರತ್ಯೇಕ ನಿಯೋಜನೆಗಾಗಿ ಆಂತರಿಕ 1C ಸಿಸ್ಟಂನಲ್ಲಿ ರಚಿಸಲಾಗಿದೆ ಮತ್ತು ಎಲ್ಲಾ ಸೈಟ್‌ಗಳಲ್ಲಿ ಮತ್ತು ಎಲ್ಲಾ ಆಡ್‌ಸರ್ವಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ ಪ್ರಚಾರಗಳು, ನಿಯೋಜನೆಗಳು ಮತ್ತು ಕೌಂಟರ್‌ಗಳಿಗೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ. ಎಲ್ಲಾ ನಿಯೋಜನೆಗಳಲ್ಲಿ 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 ಘಟಕವನ್ನು ಬಳಸಿಕೊಂಡು ಫಾರ್ಮ್‌ಗೆ ಸಲ್ಲಿಸಲಾಗುತ್ತದೆ. ಈ ರೀತಿಯಾಗಿ, ಬಳಕೆದಾರರು ಡೇಟಾವನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡುವ ಖಾತೆಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಸಾಧ್ಯವಾಯಿತು.

ಸೈಟ್‌ಗಳಲ್ಲಿ ಇರುವ ವಿನಂತಿಯ ಮಿತಿಗಳನ್ನು ಅನುಸರಿಸಲು, ನಾವು ಒಂದು ಟೋಕನ್‌ನಲ್ಲಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಗಾಗಿ ವಿನಂತಿಗಳನ್ನು ಸಂಯೋಜಿಸುತ್ತೇವೆ, ಆದರೆ ನಾವು ವಿಭಿನ್ನ ಟೋಕನ್‌ಗಳನ್ನು ಸಮಾನಾಂತರವಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬಹುದು.

ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಕನೆಕ್ಟರ್‌ಗಳೆರಡಕ್ಕೂ ಲೋಡ್ ಮಾಡಲಾದ ಡೇಟಾಕ್ಕಾಗಿ ನಾವು MongoDB ಅನ್ನು ಶೇಖರಣೆಯಾಗಿ ಆಯ್ಕೆ ಮಾಡಿದ್ದೇವೆ, ಇದು ಅಭಿವೃದ್ಧಿಯ ಆರಂಭಿಕ ಹಂತಗಳಲ್ಲಿ ಡೇಟಾ ರಚನೆಯ ಬಗ್ಗೆ ಹೆಚ್ಚು ಚಿಂತಿಸದಿರಲು ನಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು, ಅಪ್ಲಿಕೇಶನ್‌ನ ವಸ್ತು ಮಾದರಿಯು ಪ್ರತಿ ದಿನವೂ ಬದಲಾದಾಗ.

ಮೊಂಗೊಡಿಬಿಯಲ್ಲಿ ಎಲ್ಲಾ ಡೇಟಾವು ಸರಿಯಾಗಿ ಹೊಂದಿಕೊಳ್ಳುವುದಿಲ್ಲ ಎಂದು ನಾವು ಶೀಘ್ರದಲ್ಲೇ ಕಂಡುಕೊಂಡಿದ್ದೇವೆ ಮತ್ತು ಉದಾಹರಣೆಗೆ, ಸಂಬಂಧಿತ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ದೈನಂದಿನ ಅಂಕಿಅಂಶಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಇದು ಹೆಚ್ಚು ಅನುಕೂಲಕರವಾಗಿದೆ. ಆದ್ದರಿಂದ, ಸಂಬಂಧಿತ ಡೇಟಾಬೇಸ್‌ಗೆ ಡೇಟಾ ರಚನೆಯು ಹೆಚ್ಚು ಸೂಕ್ತವಾದ ಕನೆಕ್ಟರ್‌ಗಳಿಗಾಗಿ, ನಾವು PostgreSQL ಅಥವಾ MS SQL ಸರ್ವರ್ ಅನ್ನು ಸಂಗ್ರಹಣೆಯಾಗಿ ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ.

ಆಯ್ಕೆಮಾಡಿದ ವಾಸ್ತುಶಿಲ್ಪ ಮತ್ತು ತಂತ್ರಜ್ಞಾನಗಳು D1.Digital ಉತ್ಪನ್ನವನ್ನು ತುಲನಾತ್ಮಕವಾಗಿ ತ್ವರಿತವಾಗಿ ನಿರ್ಮಿಸಲು ಮತ್ತು ಪ್ರಾರಂಭಿಸಲು ನಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟವು. ಉತ್ಪನ್ನ ಅಭಿವೃದ್ಧಿಯ ಎರಡು ವರ್ಷಗಳಲ್ಲಿ, ನಾವು ಸೈಟ್‌ಗಳಿಗೆ 23 ಕನೆಕ್ಟರ್‌ಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದೇವೆ, ಮೂರನೇ ವ್ಯಕ್ತಿಯ API ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಅಮೂಲ್ಯವಾದ ಅನುಭವವನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ, ವಿಭಿನ್ನ ಸೈಟ್‌ಗಳ ಮೋಸಗಳನ್ನು ತಪ್ಪಿಸಲು ಕಲಿತಿದ್ದೇವೆ, ಪ್ರತಿಯೊಂದೂ ತಮ್ಮದೇ ಆದದ್ದು, ಕನಿಷ್ಠ 3 ರ API ಅಭಿವೃದ್ಧಿಗೆ ಕೊಡುಗೆ ನೀಡಿದೆ. ಸೈಟ್‌ಗಳು, ಸುಮಾರು 15 ಪ್ರಚಾರಗಳಲ್ಲಿ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಡೌನ್‌ಲೋಡ್ ಮಾಡಿದ ಮಾಹಿತಿಯನ್ನು ಮತ್ತು 000 ಕ್ಕೂ ಹೆಚ್ಚು ನಿಯೋಜನೆಗಳಿಗಾಗಿ, ಉತ್ಪನ್ನದ ಕಾರ್ಯಾಚರಣೆಯ ಕುರಿತು ಬಳಕೆದಾರರಿಂದ ಸಾಕಷ್ಟು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸಂಗ್ರಹಿಸಿದೆ ಮತ್ತು ಈ ಪ್ರತಿಕ್ರಿಯೆಯ ಆಧಾರದ ಮೇಲೆ ಉತ್ಪನ್ನದ ಮುಖ್ಯ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹಲವಾರು ಬಾರಿ ಬದಲಾಯಿಸುವಲ್ಲಿ ಯಶಸ್ವಿಯಾಗಿದೆ.

ಪರಿಹಾರ ವಾಸ್ತುಶಿಲ್ಪ 2.0

ಅಭಿವೃದ್ಧಿ ಪ್ರಾರಂಭವಾಗಿ ಎರಡು ವರ್ಷಗಳು ಕಳೆದಿವೆ D1.ಡಿಜಿಟಲ್. ಸಿಸ್ಟಂನಲ್ಲಿನ ಲೋಡ್ನಲ್ಲಿ ನಿರಂತರ ಹೆಚ್ಚಳ ಮತ್ತು ಹೆಚ್ಚು ಹೆಚ್ಚು ಹೊಸ ಡೇಟಾ ಮೂಲಗಳ ಹೊರಹೊಮ್ಮುವಿಕೆಯು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪರಿಹಾರ ವಾಸ್ತುಶಿಲ್ಪದಲ್ಲಿನ ಸಮಸ್ಯೆಗಳನ್ನು ಕ್ರಮೇಣ ಬಹಿರಂಗಪಡಿಸಿತು.

ಮೊದಲ ಸಮಸ್ಯೆಯು ಸೈಟ್‌ಗಳಿಂದ ಡೌನ್‌ಲೋಡ್ ಮಾಡಿದ ಡೇಟಾದ ಪ್ರಮಾಣಕ್ಕೆ ಸಂಬಂಧಿಸಿದೆ. ದೊಡ್ಡ ಸೈಟ್‌ಗಳಿಂದ ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ಮತ್ತು ನವೀಕರಿಸಲು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂಬ ಅಂಶವನ್ನು ನಾವು ಎದುರಿಸಿದ್ದೇವೆ. ಉದಾಹರಣೆಗೆ, ಹೆಚ್ಚಿನ ನಿಯೋಜನೆಗಳಿಗಾಗಿ ನಾವು ಅಂಕಿಅಂಶಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವ AdRiver ಜಾಹೀರಾತು ವ್ಯವಸ್ಥೆಯಿಂದ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವುದು ಸುಮಾರು 12 ಗಂಟೆಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.

ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, ನಾವು ಸೈಟ್‌ಗಳಿಂದ ಡೇಟಾವನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಲು ಎಲ್ಲಾ ರೀತಿಯ ವರದಿಗಳನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ, ನಾವು ಸೈಟ್‌ಗಳೊಂದಿಗೆ ಅವರ API ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇವೆ ಇದರಿಂದ ಅದರ ಕಾರ್ಯಾಚರಣೆಯ ವೇಗವು ನಮ್ಮ ಅಗತ್ಯಗಳನ್ನು ಪೂರೈಸುತ್ತದೆ ಮತ್ತು ಡೇಟಾ ಡೌನ್‌ಲೋಡ್ ಅನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಸಮಾನಾಂತರಗೊಳಿಸುತ್ತದೆ.

ಡೌನ್‌ಲೋಡ್ ಮಾಡಿದ ಡೇಟಾದ ಪ್ರಕ್ರಿಯೆಗೆ ಮತ್ತೊಂದು ಸಮಸ್ಯೆ ಸಂಬಂಧಿಸಿದೆ. ಈಗ, ಹೊಸ ಪ್ಲೇಸ್‌ಮೆಂಟ್ ಅಂಕಿಅಂಶಗಳು ಬಂದಾಗ, ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಮರು ಲೆಕ್ಕಾಚಾರ ಮಾಡುವ ಬಹು-ಹಂತದ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ, ಇದರಲ್ಲಿ ಕಚ್ಚಾ ಡೇಟಾವನ್ನು ಲೋಡ್ ಮಾಡುವುದು, ಪ್ರತಿ ಸೈಟ್‌ಗೆ ಒಟ್ಟು ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುವುದು, ವಿಭಿನ್ನ ಮೂಲಗಳಿಂದ ಡೇಟಾವನ್ನು ಪರಸ್ಪರ ಹೋಲಿಸುವುದು ಮತ್ತು ಪ್ರಚಾರಕ್ಕಾಗಿ ಸಾರಾಂಶ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುವುದು. ಇದು ಎಲ್ಲಾ ಲೆಕ್ಕಾಚಾರಗಳನ್ನು ಮಾಡುವ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಬಹಳಷ್ಟು ಲೋಡ್ ಅನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಹಲವಾರು ಬಾರಿ, ಮರು ಲೆಕ್ಕಾಚಾರದ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ, ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ನಲ್ಲಿನ ಎಲ್ಲಾ ಮೆಮೊರಿಯನ್ನು ಸುಮಾರು 10-15 ಜಿಬಿ ಸೇವಿಸಿತು, ಇದು ಸಿಸ್ಟಮ್‌ನೊಂದಿಗೆ ಬಳಕೆದಾರರ ಕೆಲಸದ ಮೇಲೆ ಹೆಚ್ಚು ಹಾನಿಕಾರಕ ಪರಿಣಾಮವನ್ನು ಬೀರುತ್ತದೆ.

ಗುರುತಿಸಲಾದ ಸಮಸ್ಯೆಗಳು ಮತ್ತು ಉತ್ಪನ್ನದ ಮತ್ತಷ್ಟು ಅಭಿವೃದ್ಧಿಗಾಗಿ ಮಹತ್ವಾಕಾಂಕ್ಷೆಯ ಯೋಜನೆಗಳು ಅಪ್ಲಿಕೇಶನ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಮರುಪರಿಶೀಲಿಸುವ ಅಗತ್ಯಕ್ಕೆ ಕಾರಣವಾಯಿತು.

ನಾವು ಕನೆಕ್ಟರ್ಸ್ನೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ.
ಎಲ್ಲಾ ಕನೆಕ್ಟರ್‌ಗಳು ಒಂದೇ ಮಾದರಿಯ ಪ್ರಕಾರ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಎಂದು ನಾವು ಗಮನಿಸಿದ್ದೇವೆ, ಆದ್ದರಿಂದ ನಾವು ಕನೆಕ್ಟರ್ ಅನ್ನು ರಚಿಸಲು ಪೈಪ್‌ಲೈನ್ ಚೌಕಟ್ಟನ್ನು ನಿರ್ಮಿಸಿದ್ದೇವೆ, ಇದರಲ್ಲಿ ನೀವು ಹಂತಗಳ ತರ್ಕವನ್ನು ಮಾತ್ರ ಪ್ರೋಗ್ರಾಮ್ ಮಾಡಬೇಕಾಗಿತ್ತು, ಉಳಿದವು ಸಾರ್ವತ್ರಿಕವಾಗಿದೆ. ಕೆಲವು ಕನೆಕ್ಟರ್‌ಗೆ ಸುಧಾರಣೆಯ ಅಗತ್ಯವಿದ್ದರೆ, ಕನೆಕ್ಟರ್ ಅನ್ನು ಸುಧಾರಿಸುವ ಸಮಯದಲ್ಲಿ ನಾವು ಅದನ್ನು ತಕ್ಷಣವೇ ಹೊಸ ಚೌಕಟ್ಟಿಗೆ ವರ್ಗಾಯಿಸುತ್ತೇವೆ.

ಅದೇ ಸಮಯದಲ್ಲಿ, ನಾವು ಡಾಕರ್ ಮತ್ತು ಕುಬರ್ನೆಟ್‌ಗಳಿಗೆ ಕನೆಕ್ಟರ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ.
ನಾವು ಸಿಐ/ಸಿಡಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಪ್ರಯೋಗಿಸಿದ್ದೇವೆ, ಕುಬರ್ನೆಟ್ಸ್‌ಗೆ ಹೋಗುವುದನ್ನು ನಾವು ದೀರ್ಘಕಾಲದವರೆಗೆ ಯೋಜಿಸಿದ್ದೇವೆ, ಆದರೆ ಒಂದು ಕನೆಕ್ಟರ್ ದೋಷದಿಂದಾಗಿ ಸರ್ವರ್‌ನಲ್ಲಿ 20 GB ಗಿಂತ ಹೆಚ್ಚಿನ ಮೆಮೊರಿಯನ್ನು ತಿನ್ನಲು ಪ್ರಾರಂಭಿಸಿದಾಗ ಮಾತ್ರ ಚಲಿಸಲು ಪ್ರಾರಂಭಿಸಿದೆವು, ಪ್ರಾಯೋಗಿಕವಾಗಿ ಇತರ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಕೊಲ್ಲುತ್ತದೆ. . ತನಿಖೆಯ ಸಮಯದಲ್ಲಿ, ಕನೆಕ್ಟರ್ ಅನ್ನು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗೆ ಸರಿಸಲಾಗಿದೆ, ದೋಷವನ್ನು ಸರಿಪಡಿಸಿದ ನಂತರವೂ ಅದು ಅಂತಿಮವಾಗಿ ಉಳಿಯಿತು.

ಕುಬರ್ನೆಟ್ಸ್ ಅನುಕೂಲಕರವಾಗಿದೆ ಎಂದು ನಾವು ಬೇಗನೆ ಅರಿತುಕೊಂಡೆವು ಮತ್ತು ಆರು ತಿಂಗಳೊಳಗೆ ನಾವು 7 ಕನೆಕ್ಟರ್‌ಗಳು ಮತ್ತು ಹೆಚ್ಚಿನ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸುವ ಕನೆಕ್ಟರ್‌ಗಳ ಪ್ರಾಕ್ಸಿಯನ್ನು ಉತ್ಪಾದನಾ ಕ್ಲಸ್ಟರ್‌ಗೆ ವರ್ಗಾಯಿಸಿದ್ದೇವೆ.

ಕನೆಕ್ಟರ್‌ಗಳನ್ನು ಅನುಸರಿಸಿ, ಉಳಿದ ಅಪ್ಲಿಕೇಶನ್‌ನ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಬದಲಾಯಿಸಲು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ.
ಮುಖ್ಯ ಸಮಸ್ಯೆಯೆಂದರೆ ಡೇಟಾವು ಕನೆಕ್ಟರ್‌ಗಳಿಂದ ದೊಡ್ಡ ಬ್ಯಾಚ್‌ಗಳಲ್ಲಿ ಪ್ರಾಕ್ಸಿಗಳಿಗೆ ಬರುತ್ತದೆ, ಮತ್ತು ನಂತರ DANBoID ಅನ್ನು ಹಿಟ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗಾಗಿ ಕೇಂದ್ರ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಮೆಟ್ರಿಕ್ಸ್ ಮರು ಲೆಕ್ಕಾಚಾರಗಳ ಕಾರಣ, ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಹೆಚ್ಚಿನ ಹೊರೆ ಇದೆ.

ವೈಯಕ್ತಿಕ ಡೇಟಾ ಸಂಗ್ರಹಣೆ ಕೆಲಸಗಳ ಸ್ಥಿತಿಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು ಮತ್ತು ಕೇಂದ್ರೀಯ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಕನೆಕ್ಟರ್‌ಗಳಲ್ಲಿ ಸಂಭವಿಸುವ ದೋಷಗಳನ್ನು ವರದಿ ಮಾಡುವುದು ತುಂಬಾ ಕಷ್ಟಕರವೆಂದು ಸಾಬೀತಾಯಿತು, ಇದರಿಂದಾಗಿ ಬಳಕೆದಾರರು ಏನಾಗುತ್ತಿದೆ ಮತ್ತು ಡೇಟಾವನ್ನು ಏಕೆ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತಿಲ್ಲ ಎಂಬುದನ್ನು ನೋಡಬಹುದು.

ಈ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು, ನಾವು ಆರ್ಕಿಟೆಕ್ಚರ್ 2.0 ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದೇವೆ.

ಆರ್ಕಿಟೆಕ್ಚರ್‌ನ ಹೊಸ ಆವೃತ್ತಿಯ ನಡುವಿನ ಪ್ರಮುಖ ವ್ಯತ್ಯಾಸವೆಂದರೆ ವೆಬ್ API ಬದಲಿಗೆ, ನಾವು ಸೇವೆಗಳ ನಡುವೆ ಸಂದೇಶಗಳನ್ನು ವಿನಿಮಯ ಮಾಡಲು RabbitMQ ಮತ್ತು MassTransit ಲೈಬ್ರರಿಯನ್ನು ಬಳಸುತ್ತೇವೆ. ಇದನ್ನು ಮಾಡಲು, ನಾವು ಕನೆಕ್ಟರ್ಸ್ ಪ್ರಾಕ್ಸಿಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪುನಃ ಬರೆಯಬೇಕಾಗಿತ್ತು, ಅದನ್ನು ಕನೆಕ್ಟರ್ಸ್ ಹಬ್ ಆಗಿ ಮಾಡುತ್ತದೆ. ಹೆಸರನ್ನು ಬದಲಾಯಿಸಲಾಗಿದೆ ಏಕೆಂದರೆ ಸೇವೆಯ ಮುಖ್ಯ ಪಾತ್ರವು ಇನ್ನು ಮುಂದೆ ವಿನಂತಿಗಳನ್ನು ಕನೆಕ್ಟರ್‌ಗಳಿಗೆ ಮತ್ತು ಹಿಂದಕ್ಕೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುವುದಿಲ್ಲ, ಆದರೆ ಕನೆಕ್ಟರ್‌ಗಳಿಂದ ಮೆಟ್ರಿಕ್‌ಗಳ ಸಂಗ್ರಹವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ.

ಕೇಂದ್ರೀಯ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ, ನಾವು ಸೈಟ್‌ಗಳಿಂದ ನಿಯೋಜನೆಗಳು ಮತ್ತು ಅಂಕಿಅಂಶಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಪ್ರತ್ಯೇಕ ಸೇವೆಗಳಾಗಿ ಬೇರ್ಪಡಿಸಿದ್ದೇವೆ, ಇದು ಅನಗತ್ಯ ಮರು ಲೆಕ್ಕಾಚಾರಗಳನ್ನು ತೊಡೆದುಹಾಕಲು ಮತ್ತು ಪ್ಲೇಸ್‌ಮೆಂಟ್ ಮಟ್ಟದಲ್ಲಿ ಈಗಾಗಲೇ ಲೆಕ್ಕಹಾಕಿದ ಮತ್ತು ಒಟ್ಟುಗೂಡಿದ ಅಂಕಿಅಂಶಗಳನ್ನು ಮಾತ್ರ ಸಂಗ್ರಹಿಸಲು ಸಾಧ್ಯವಾಗಿಸಿತು. ಕಚ್ಚಾ ಡೇಟಾದ ಆಧಾರದ ಮೇಲೆ ಮೂಲ ಅಂಕಿಅಂಶಗಳನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ನಾವು ತರ್ಕವನ್ನು ಪುನಃ ಬರೆದಿದ್ದೇವೆ ಮತ್ತು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದ್ದೇವೆ.

ಅದೇ ಸಮಯದಲ್ಲಿ, ಪರಿಹಾರವನ್ನು ಅಳೆಯಲು ಮತ್ತು ನಿರ್ವಹಿಸಲು ಹೆಚ್ಚು ಅನುಕೂಲಕರವಾಗಿಸಲು ನಾವು ಎಲ್ಲಾ ಸೇವೆಗಳು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಡಾಕರ್ ಮತ್ತು ಕುಬರ್ನೆಟ್‌ಗಳಿಗೆ ಸ್ಥಳಾಂತರಿಸುತ್ತಿದ್ದೇವೆ.

ನಾವೀಗ ಎಲ್ಲಿದ್ದೇವೆ

ಪ್ರೂಫ್-ಆಫ್-ಕಾನ್ಸೆಪ್ಟ್ ಆರ್ಕಿಟೆಕ್ಚರ್ 2.0 ಉತ್ಪನ್ನ D1.ಡಿಜಿಟಲ್ ಸೀಮಿತ ಕನೆಕ್ಟರ್‌ಗಳೊಂದಿಗೆ ಪರೀಕ್ಷಾ ಪರಿಸರದಲ್ಲಿ ಸಿದ್ಧವಾಗಿದೆ ಮತ್ತು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ. ಇನ್ನೂ 20 ಕನೆಕ್ಟರ್‌ಗಳನ್ನು ಹೊಸ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗೆ ಪುನಃ ಬರೆಯುವುದು, ಡೇಟಾವನ್ನು ಸರಿಯಾಗಿ ಲೋಡ್ ಮಾಡಲಾಗಿದೆಯೇ ಮತ್ತು ಎಲ್ಲಾ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸರಿಯಾಗಿ ಲೆಕ್ಕಹಾಕಲಾಗಿದೆಯೇ ಎಂದು ಪರೀಕ್ಷಿಸುವುದು ಮತ್ತು ಸಂಪೂರ್ಣ ವಿನ್ಯಾಸವನ್ನು ಉತ್ಪಾದನೆಗೆ ಹೊರತರುವುದು ಮಾತ್ರ ಉಳಿದಿದೆ.

ವಾಸ್ತವವಾಗಿ, ಈ ಪ್ರಕ್ರಿಯೆಯು ಕ್ರಮೇಣ ಸಂಭವಿಸುತ್ತದೆ ಮತ್ತು ಎಲ್ಲವನ್ನೂ ಕೆಲಸ ಮಾಡಲು ನಾವು ಹಳೆಯ API ಗಳೊಂದಿಗೆ ಹಿಂದುಳಿದ ಹೊಂದಾಣಿಕೆಯನ್ನು ಬಿಡಬೇಕಾಗುತ್ತದೆ.

ನಮ್ಮ ತಕ್ಷಣದ ಯೋಜನೆಗಳು ಹೊಸ ಕನೆಕ್ಟರ್‌ಗಳ ಅಭಿವೃದ್ಧಿ, ಹೊಸ ಸಿಸ್ಟಮ್‌ಗಳೊಂದಿಗೆ ಏಕೀಕರಣ ಮತ್ತು ಸಂಪರ್ಕಿತ ಸೈಟ್‌ಗಳು ಮತ್ತು ಜಾಹೀರಾತು ವ್ಯವಸ್ಥೆಗಳಿಂದ ಡೌನ್‌ಲೋಡ್ ಮಾಡಲಾದ ಡೇಟಾದ ಸೆಟ್‌ಗೆ ಹೆಚ್ಚುವರಿ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸೇರಿಸುವುದು.

ಕೇಂದ್ರೀಯ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ ಸೇರಿದಂತೆ ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಡಾಕರ್ ಮತ್ತು ಕುಬರ್ನೆಟ್‌ಗಳಿಗೆ ವರ್ಗಾಯಿಸಲು ನಾವು ಯೋಜಿಸುತ್ತೇವೆ. ಹೊಸ ವಾಸ್ತುಶೈಲಿಯೊಂದಿಗೆ ಸಂಯೋಜಿಸಿ, ಇದು ನಿಯೋಜನೆ, ಮೇಲ್ವಿಚಾರಣೆ ಮತ್ತು ಸೇವಿಸಿದ ಸಂಪನ್ಮೂಲಗಳ ನಿಯಂತ್ರಣವನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಸರಳಗೊಳಿಸುತ್ತದೆ.

ಅಂಕಿಅಂಶಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಡೇಟಾಬೇಸ್‌ನ ಆಯ್ಕೆಯೊಂದಿಗೆ ಪ್ರಯೋಗ ಮಾಡುವುದು ಮತ್ತೊಂದು ಆಲೋಚನೆಯಾಗಿದೆ, ಇದನ್ನು ಪ್ರಸ್ತುತ ಮೊಂಗೊಡಿಬಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ. ನಾವು ಈಗಾಗಲೇ ಹಲವಾರು ಹೊಸ ಕನೆಕ್ಟರ್‌ಗಳನ್ನು SQL ಡೇಟಾಬೇಸ್‌ಗಳಿಗೆ ವರ್ಗಾಯಿಸಿದ್ದೇವೆ, ಆದರೆ ವ್ಯತ್ಯಾಸವು ಬಹುತೇಕ ಗಮನಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಅನಿಯಂತ್ರಿತ ಅವಧಿಗೆ ವಿನಂತಿಸಬಹುದಾದ ದಿನದ ಒಟ್ಟು ಅಂಕಿಅಂಶಗಳಿಗೆ, ಲಾಭವು ತುಂಬಾ ಗಂಭೀರವಾಗಿರುತ್ತದೆ.

ಸಾಮಾನ್ಯವಾಗಿ, ಯೋಜನೆಗಳು ಭವ್ಯವಾಗಿವೆ, ನಾವು ಮುಂದುವರಿಯೋಣ :)

ಲೇಖನದ ಲೇಖಕರು ಆರ್&ಡಿ ಡೆಂಟ್ಸು ಏಜಿಸ್ ನೆಟ್‌ವರ್ಕ್ ರಷ್ಯಾ: ಜಾರ್ಜಿ ಒಸ್ಟಾಪೆಂಕೊ (ಶ್ಮಿಗಾ), ಮಿಖಾಯಿಲ್ ಕೋಟ್ಸಿಕ್ (ಹಿಟೆಕ್ಸ್)

ಮೂಲ: www.habr.com