ਅਸੀਂ ਔਨਲਾਈਨ ਸਾਈਟਾਂ ਤੋਂ ਵਿਗਿਆਪਨ ਮੁਹਿੰਮਾਂ 'ਤੇ ਡੇਟਾ ਕਿਵੇਂ ਇਕੱਠਾ ਕੀਤਾ (ਉਤਪਾਦ ਲਈ ਕੰਡੇਦਾਰ ਮਾਰਗ)

ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਔਨਲਾਈਨ ਵਿਗਿਆਪਨ ਦਾ ਖੇਤਰ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਉੱਨਤ ਅਤੇ ਸਵੈਚਾਲਿਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ. ਬੇਸ਼ੱਕ, ਕਿਉਂਕਿ ਯਾਂਡੇਕਸ, ਮੇਲ.ਆਰਯੂ, ਗੂਗਲ ਅਤੇ ਫੇਸਬੁੱਕ ਵਰਗੇ ਉਨ੍ਹਾਂ ਦੇ ਖੇਤਰ ਵਿੱਚ ਅਜਿਹੇ ਦਿੱਗਜ ਅਤੇ ਮਾਹਰ ਉੱਥੇ ਕੰਮ ਕਰਦੇ ਹਨ. ਪਰ, ਜਿਵੇਂ ਕਿ ਇਹ ਨਿਕਲਿਆ, ਸੰਪੂਰਨਤਾ ਦੀ ਕੋਈ ਸੀਮਾ ਨਹੀਂ ਹੈ ਅਤੇ ਸਵੈਚਾਲਤ ਕਰਨ ਲਈ ਹਮੇਸ਼ਾਂ ਕੁਝ ਹੁੰਦਾ ਹੈ.

ਸਰੋਤ

ਸੰਚਾਰ ਸਮੂਹ Dentsu Aegis ਨੈੱਟਵਰਕ ਰੂਸ ਡਿਜੀਟਲ ਵਿਗਿਆਪਨ ਬਾਜ਼ਾਰ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਡਾ ਖਿਡਾਰੀ ਹੈ ਅਤੇ ਸਰਗਰਮੀ ਨਾਲ ਤਕਨਾਲੋਜੀ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰ ਰਿਹਾ ਹੈ, ਆਪਣੀਆਂ ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਅਨੁਕੂਲਿਤ ਅਤੇ ਸਵੈਚਾਲਿਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ। ਔਨਲਾਈਨ ਵਿਗਿਆਪਨ ਬਾਜ਼ਾਰ ਦੀਆਂ ਅਣਸੁਲਝੀਆਂ ਸਮੱਸਿਆਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵੱਖ-ਵੱਖ ਇੰਟਰਨੈਟ ਪਲੇਟਫਾਰਮਾਂ ਤੋਂ ਵਿਗਿਆਪਨ ਮੁਹਿੰਮਾਂ ਦੇ ਅੰਕੜੇ ਇਕੱਠੇ ਕਰਨ ਦਾ ਕੰਮ ਬਣ ਗਿਆ ਹੈ। ਇਸ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਆਖਰਕਾਰ ਇੱਕ ਉਤਪਾਦ ਦੀ ਸਿਰਜਣਾ ਵਿੱਚ ਨਤੀਜਾ ਹੋਇਆ D1.ਡਿਜੀਟਲ (ਦੀਵਾਨ ਵਜੋਂ ਪੜ੍ਹੋ), ਜਿਸ ਦੇ ਵਿਕਾਸ ਬਾਰੇ ਅਸੀਂ ਗੱਲ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ।

ਕਿਉਂ?

1. ਪ੍ਰੋਜੈਕਟ ਦੀ ਸ਼ੁਰੂਆਤ ਦੇ ਸਮੇਂ, ਮਾਰਕੀਟ ਵਿੱਚ ਇੱਕ ਵੀ ਤਿਆਰ ਉਤਪਾਦ ਨਹੀਂ ਸੀ ਜੋ ਵਿਗਿਆਪਨ ਮੁਹਿੰਮਾਂ 'ਤੇ ਅੰਕੜਿਆਂ ਦੇ ਸੰਗ੍ਰਹਿ ਨੂੰ ਸਵੈਚਾਲਤ ਕਰਨ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੋਵੇ। ਇਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਾਡੇ ਤੋਂ ਇਲਾਵਾ ਕੋਈ ਵੀ ਸਾਡੀਆਂ ਲੋੜਾਂ ਪੂਰੀਆਂ ਨਹੀਂ ਕਰੇਗਾ।

ਇਮਪ੍ਰੋਵਾਡੋ, ਰੋਇਸਟੈਟ, ਸੁਪਰਮੈਟ੍ਰਿਕਸ, ਸੈਗਮੈਂਟਸਟ੍ਰੀਮ ਵਰਗੀਆਂ ਸੇਵਾਵਾਂ ਪਲੇਟਫਾਰਮਾਂ, ਸੋਸ਼ਲ ਨੈਟਵਰਕਸ ਅਤੇ ਗੂਗਲ ਐਨਾਲਿਟਿਕਸ ਦੇ ਨਾਲ ਏਕੀਕਰਣ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਵਿਗਿਆਪਨ ਮੁਹਿੰਮਾਂ ਦੇ ਸੁਵਿਧਾਜਨਕ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਨਿਯੰਤਰਣ ਲਈ ਵਿਸ਼ਲੇਸ਼ਣਾਤਮਕ ਡੈਸ਼ਬੋਰਡ ਬਣਾਉਣਾ ਵੀ ਸੰਭਵ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਸਾਡੇ ਉਤਪਾਦ ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਅਸੀਂ ਸਾਈਟਾਂ ਤੋਂ ਡੇਟਾ ਇਕੱਠਾ ਕਰਨ ਲਈ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ, ਪਰ, ਬਦਕਿਸਮਤੀ ਨਾਲ, ਉਹ ਸਾਡੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਨਹੀਂ ਕਰ ਸਕੇ।

ਮੁੱਖ ਸਮੱਸਿਆ ਇਹ ਸੀ ਕਿ ਟੈਸਟ ਕੀਤੇ ਉਤਪਾਦ ਡੇਟਾ ਸਰੋਤਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਸਨ, ਸਾਈਟ ਦੁਆਰਾ ਪਲੇਸਮੈਂਟ ਦੇ ਅੰਕੜੇ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦੇ ਸਨ, ਅਤੇ ਵਿਗਿਆਪਨ ਮੁਹਿੰਮਾਂ 'ਤੇ ਅੰਕੜੇ ਇਕੱਠੇ ਕਰਨ ਦੀ ਯੋਗਤਾ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦੇ ਸਨ। ਇਸ ਪਹੁੰਚ ਨੇ ਸਾਨੂੰ ਇੱਕ ਥਾਂ 'ਤੇ ਵੱਖ-ਵੱਖ ਸਾਈਟਾਂ ਤੋਂ ਅੰਕੜੇ ਦੇਖਣ ਅਤੇ ਮੁਹਿੰਮ ਦੀ ਸਥਿਤੀ ਦਾ ਸਮੁੱਚੇ ਤੌਰ 'ਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੱਤੀ।

ਇਕ ਹੋਰ ਕਾਰਕ ਇਹ ਸੀ ਕਿ ਸ਼ੁਰੂਆਤੀ ਪੜਾਵਾਂ 'ਤੇ ਉਤਪਾਦਾਂ ਦਾ ਉਦੇਸ਼ ਪੱਛਮੀ ਮਾਰਕੀਟ 'ਤੇ ਸੀ ਅਤੇ ਰੂਸੀ ਸਾਈਟਾਂ ਨਾਲ ਏਕੀਕਰਣ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦੇ ਸਨ। ਅਤੇ ਉਹਨਾਂ ਸਾਈਟਾਂ ਲਈ ਜਿਨ੍ਹਾਂ ਦੇ ਨਾਲ ਏਕੀਕਰਣ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਸੀ, ਸਾਰੇ ਜ਼ਰੂਰੀ ਮੈਟ੍ਰਿਕਸ ਹਮੇਸ਼ਾ ਲੋੜੀਂਦੇ ਵੇਰਵੇ ਨਾਲ ਡਾਊਨਲੋਡ ਨਹੀਂ ਕੀਤੇ ਗਏ ਸਨ, ਅਤੇ ਏਕੀਕਰਣ ਹਮੇਸ਼ਾ ਸੁਵਿਧਾਜਨਕ ਅਤੇ ਪਾਰਦਰਸ਼ੀ ਨਹੀਂ ਸੀ, ਖਾਸ ਤੌਰ 'ਤੇ ਜਦੋਂ ਇਹ ਕੁਝ ਪ੍ਰਾਪਤ ਕਰਨਾ ਜ਼ਰੂਰੀ ਸੀ ਜੋ ਸਿਸਟਮ ਇੰਟਰਫੇਸ ਵਿੱਚ ਨਹੀਂ ਹੈ.
ਆਮ ਤੌਰ 'ਤੇ, ਅਸੀਂ ਤੀਜੀ-ਧਿਰ ਦੇ ਉਤਪਾਦਾਂ ਦੇ ਅਨੁਕੂਲ ਨਾ ਹੋਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ, ਪਰ ਆਪਣੇ ਖੁਦ ਦੇ ਵਿਕਾਸ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ...

2. ਔਨਲਾਈਨ ਵਿਗਿਆਪਨ ਬਾਜ਼ਾਰ ਸਾਲ-ਦਰ-ਸਾਲ ਵਧ ਰਿਹਾ ਹੈ, ਅਤੇ 2018 ਵਿੱਚ, ਵਿਗਿਆਪਨ ਬਜਟ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਇਸਨੇ ਰਵਾਇਤੀ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਵੱਡੇ ਟੀਵੀ ਵਿਗਿਆਪਨ ਬਾਜ਼ਾਰ ਨੂੰ ਪਛਾੜ ਦਿੱਤਾ। ਇਸ ਲਈ ਇੱਕ ਪੈਮਾਨਾ ਹੈ.

3. ਟੀਵੀ ਵਿਗਿਆਪਨ ਬਾਜ਼ਾਰ ਦੇ ਉਲਟ, ਜਿੱਥੇ ਵਪਾਰਕ ਵਿਗਿਆਪਨ ਦੀ ਵਿਕਰੀ 'ਤੇ ਏਕਾਧਿਕਾਰ ਹੈ, ਉੱਥੇ ਬਹੁਤ ਸਾਰੇ ਵਿਅਕਤੀਗਤ ਮਾਲਕ ਆਪਣੇ ਖੁਦ ਦੇ ਵਿਗਿਆਪਨ ਖਾਤਿਆਂ ਨਾਲ ਇੰਟਰਨੈੱਟ 'ਤੇ ਕੰਮ ਕਰਦੇ ਵੱਖ-ਵੱਖ ਆਕਾਰਾਂ ਦੀਆਂ ਵਿਗਿਆਪਨ ਸੂਚੀਆਂ ਦੇ ਮਾਲਕ ਹਨ। ਕਿਉਂਕਿ ਇੱਕ ਵਿਗਿਆਪਨ ਮੁਹਿੰਮ, ਇੱਕ ਨਿਯਮ ਦੇ ਤੌਰ ਤੇ, ਇੱਕ ਵਾਰ ਵਿੱਚ ਕਈ ਸਾਈਟਾਂ 'ਤੇ ਚੱਲਦੀ ਹੈ, ਵਿਗਿਆਪਨ ਮੁਹਿੰਮ ਦੀ ਸਥਿਤੀ ਨੂੰ ਸਮਝਣ ਲਈ, ਸਾਰੀਆਂ ਸਾਈਟਾਂ ਤੋਂ ਰਿਪੋਰਟਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਨਾ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਵੱਡੀ ਰਿਪੋਰਟ ਵਿੱਚ ਜੋੜਨਾ ਜ਼ਰੂਰੀ ਹੈ ਜੋ ਪੂਰੀ ਤਸਵੀਰ ਦਿਖਾਏਗੀ. ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਓਪਟੀਮਾਈਜੇਸ਼ਨ ਦੀ ਸੰਭਾਵਨਾ ਹੈ.

4. ਇਹ ਸਾਨੂੰ ਜਾਪਦਾ ਸੀ ਕਿ ਇੰਟਰਨੈੱਟ 'ਤੇ ਵਿਗਿਆਪਨ ਸੂਚੀ ਦੇ ਮਾਲਕਾਂ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਅੰਕੜੇ ਇਕੱਠੇ ਕਰਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਵਿਗਿਆਪਨ ਖਾਤਿਆਂ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨ ਲਈ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਹੈ, ਅਤੇ ਉਹ ਇਸ ਡੇਟਾ ਲਈ ਇੱਕ API ਪ੍ਰਦਾਨ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਗੇ। ਇਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਸ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਸੰਭਵ ਹੈ। ਆਓ ਤੁਰੰਤ ਕਹਿ ਦੇਈਏ ਕਿ ਇਹ ਇੰਨਾ ਸਧਾਰਨ ਨਹੀਂ ਸੀ.

ਆਮ ਤੌਰ 'ਤੇ, ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਸਾਰੀਆਂ ਸ਼ਰਤਾਂ ਸਾਡੇ ਲਈ ਸਪੱਸ਼ਟ ਸਨ, ਅਤੇ ਅਸੀਂ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਜੀਵਨ ਵਿੱਚ ਲਿਆਉਣ ਲਈ ਦੌੜੇ ...

ਮਹਾਨ ਯੋਜਨਾ

ਸ਼ੁਰੂ ਕਰਨ ਲਈ, ਅਸੀਂ ਇੱਕ ਆਦਰਸ਼ ਪ੍ਰਣਾਲੀ ਦਾ ਇੱਕ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਬਣਾਇਆ:

• 1C ਕਾਰਪੋਰੇਟ ਸਿਸਟਮ ਤੋਂ ਵਿਗਿਆਪਨ ਮੁਹਿੰਮਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਉਹਨਾਂ ਦੇ ਨਾਮ, ਮਿਆਦ, ਬਜਟ ਅਤੇ ਪਲੇਸਮੈਂਟ ਦੇ ਨਾਲ ਆਪਣੇ ਆਪ ਇਸ ਵਿੱਚ ਲੋਡ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
• ਇੱਕ ਵਿਗਿਆਪਨ ਮੁਹਿੰਮ ਦੇ ਅੰਦਰ ਹਰੇਕ ਪਲੇਸਮੈਂਟ ਲਈ, ਸਾਰੇ ਸੰਭਵ ਅੰਕੜੇ ਉਹਨਾਂ ਸਾਈਟਾਂ ਤੋਂ ਆਪਣੇ ਆਪ ਡਾਊਨਲੋਡ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ ਜਿੱਥੇ ਪਲੇਸਮੈਂਟ ਹੋ ਰਹੀ ਹੈ, ਜਿਵੇਂ ਕਿ ਛਾਪਾਂ, ਕਲਿੱਕਾਂ, ਦ੍ਰਿਸ਼ਾਂ ਦੀ ਗਿਣਤੀ, ਆਦਿ।
• ਕੁਝ ਵਿਗਿਆਪਨ ਮੁਹਿੰਮਾਂ ਨੂੰ ਅਖੌਤੀ ਵਿਗਿਆਪਨ ਪ੍ਰਣਾਲੀਆਂ ਜਿਵੇਂ ਕਿ ਐਡਰਾਈਵਰ, ਵੈਬੋਰਾਮਾ, ਡੀਸੀਐਮ, ਆਦਿ ਦੁਆਰਾ ਤੀਜੀ-ਧਿਰ ਦੀ ਨਿਗਰਾਨੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਟਰੈਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਰੂਸ ਵਿੱਚ ਇੱਕ ਉਦਯੋਗਿਕ ਇੰਟਰਨੈਟ ਮੀਟਰ ਵੀ ਹੈ - ਮੀਡੀਆਸਕੋਪ ਕੰਪਨੀ. ਸਾਡੀ ਯੋਜਨਾ ਦੇ ਅਨੁਸਾਰ, ਸੁਤੰਤਰ ਅਤੇ ਉਦਯੋਗਿਕ ਨਿਗਰਾਨੀ ਤੋਂ ਡਾਟਾ ਵੀ ਸੰਬੰਧਿਤ ਵਿਗਿਆਪਨ ਮੁਹਿੰਮਾਂ ਵਿੱਚ ਆਪਣੇ ਆਪ ਲੋਡ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
• ਇੰਟਰਨੈੱਟ 'ਤੇ ਜ਼ਿਆਦਾਤਰ ਵਿਗਿਆਪਨ ਮੁਹਿੰਮਾਂ ਦਾ ਉਦੇਸ਼ ਕੁਝ ਨਿਸ਼ਾਨਾ ਕਾਰਵਾਈਆਂ (ਖਰੀਦਣਾ, ਕਾਲ ਕਰਨਾ, ਟੈਸਟ ਡਰਾਈਵ ਲਈ ਸਾਈਨ ਅੱਪ ਕਰਨਾ, ਆਦਿ) ਹੈ, ਜੋ ਕਿ Google ਵਿਸ਼ਲੇਸ਼ਣ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਟ੍ਰੈਕ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਅੰਕੜੇ ਜਿਨ੍ਹਾਂ ਲਈ ਮੁਹਿੰਮ ਦੀ ਸਥਿਤੀ ਨੂੰ ਸਮਝਣ ਲਈ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹਨ ਅਤੇ ਸਾਡੇ ਟੂਲ ਵਿੱਚ ਲੋਡ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਪਹਿਲੀ ਲਾਹਨਤ ਚੀਜ਼ ਗੰਦੀ ਹੈ

ਸਾੱਫਟਵੇਅਰ ਵਿਕਾਸ ਦੇ ਲਚਕਦਾਰ ਸਿਧਾਂਤਾਂ (ਚੁਸਤ, ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ) ਪ੍ਰਤੀ ਸਾਡੀ ਵਚਨਬੱਧਤਾ ਨੂੰ ਦੇਖਦੇ ਹੋਏ, ਅਸੀਂ ਪਹਿਲਾਂ ਇੱਕ MVP ਵਿਕਸਤ ਕਰਨ ਅਤੇ ਫਿਰ ਇਰਾਦਾ ਟੀਚੇ ਵੱਲ ਦੁਹਰਾਉਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ।
ਅਸੀਂ ਆਪਣੇ ਉਤਪਾਦ ਦੇ ਆਧਾਰ 'ਤੇ MVP ਬਣਾਉਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ ਡੈਨਬੋ (ਡੈਂਟਸੂ ਏਜੀਸ ਨੈਟਵਰਕ ਬੋਰਡ), ਜੋ ਕਿ ਸਾਡੇ ਗਾਹਕਾਂ ਦੀਆਂ ਵਿਗਿਆਪਨ ਮੁਹਿੰਮਾਂ 'ਤੇ ਆਮ ਜਾਣਕਾਰੀ ਵਾਲੀ ਇੱਕ ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨ ਹੈ।

MVP ਲਈ, ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਸਰਲ ਬਣਾਇਆ ਗਿਆ ਸੀ। ਅਸੀਂ ਏਕੀਕਰਣ ਲਈ ਪਲੇਟਫਾਰਮਾਂ ਦੀ ਇੱਕ ਸੀਮਤ ਸੂਚੀ ਚੁਣੀ ਹੈ। ਇਹ ਮੁੱਖ ਪਲੇਟਫਾਰਮ ਸਨ, ਜਿਵੇਂ ਕਿ Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB, ਅਤੇ ਮੁੱਖ ਵਿਗਿਆਪਨ ਪ੍ਰਣਾਲੀਆਂ Adriver ਅਤੇ Weborama.

API ਦੁਆਰਾ ਸਾਈਟਾਂ 'ਤੇ ਅੰਕੜਿਆਂ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਲਈ, ਅਸੀਂ ਇੱਕ ਸਿੰਗਲ ਖਾਤੇ ਦੀ ਵਰਤੋਂ ਕੀਤੀ। ਇੱਕ ਗਾਹਕ ਸਮੂਹ ਪ੍ਰਬੰਧਕ ਜੋ ਇੱਕ ਵਿਗਿਆਪਨ ਮੁਹਿੰਮ 'ਤੇ ਅੰਕੜਿਆਂ ਦੇ ਸਵੈਚਲਿਤ ਸੰਗ੍ਰਹਿ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਚਾਹੁੰਦਾ ਸੀ, ਨੂੰ ਪਹਿਲਾਂ ਪਲੇਟਫਾਰਮ ਖਾਤੇ ਨੂੰ ਸਾਈਟਾਂ 'ਤੇ ਲੋੜੀਂਦੀਆਂ ਵਿਗਿਆਪਨ ਮੁਹਿੰਮਾਂ ਤੱਕ ਪਹੁੰਚ ਸੌਂਪਣੀ ਪੈਂਦੀ ਸੀ।

ਅੱਗੇ ਸਿਸਟਮ ਉਪਭੋਗਤਾ ਹੈ ਡੈਨਬੋ ਨੂੰ ਐਕਸਲ ਸਿਸਟਮ ਵਿੱਚ ਇੱਕ ਖਾਸ ਫਾਰਮੈਟ ਦੀ ਇੱਕ ਫਾਈਲ ਅਪਲੋਡ ਕਰਨੀ ਪਈ, ਜਿਸ ਵਿੱਚ ਪਲੇਸਮੈਂਟ (ਵਿਗਿਆਪਨ ਮੁਹਿੰਮ, ਪਲੇਟਫਾਰਮ, ਫਾਰਮੈਟ, ਪਲੇਸਮੈਂਟ ਪੀਰੀਅਡ, ਯੋਜਨਾਬੱਧ ਸੂਚਕਾਂ, ਬਜਟ, ਆਦਿ) ਅਤੇ ਸੰਬੰਧਿਤ ਵਿਗਿਆਪਨ ਮੁਹਿੰਮਾਂ ਦੇ ਪਛਾਣਕਰਤਾਵਾਂ ਬਾਰੇ ਸਾਰੀ ਜਾਣਕਾਰੀ ਸ਼ਾਮਲ ਸੀ। ਵਿਗਿਆਪਨ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਸਾਈਟਾਂ ਅਤੇ ਕਾਊਂਟਰ।

ਇਹ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਡਰਾਉਣਾ ਦਿਖਾਈ ਦਿੰਦਾ ਸੀ:

ਡਾਉਨਲੋਡ ਕੀਤੇ ਡੇਟਾ ਨੂੰ ਇੱਕ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਗਿਆ ਸੀ, ਅਤੇ ਫਿਰ ਵੱਖਰੀਆਂ ਸੇਵਾਵਾਂ ਨੇ ਉਹਨਾਂ ਤੋਂ ਸਾਈਟਾਂ 'ਤੇ ਮੁਹਿੰਮ ਪਛਾਣਕਰਤਾ ਇਕੱਠੇ ਕੀਤੇ ਅਤੇ ਉਹਨਾਂ 'ਤੇ ਅੰਕੜੇ ਡਾਊਨਲੋਡ ਕੀਤੇ।

ਹਰੇਕ ਸਾਈਟ ਲਈ, ਇੱਕ ਵੱਖਰੀ ਵਿੰਡੋਜ਼ ਸੇਵਾ ਲਿਖੀ ਗਈ ਸੀ, ਜੋ ਦਿਨ ਵਿੱਚ ਇੱਕ ਵਾਰ ਸਾਈਟ ਦੇ API ਵਿੱਚ ਇੱਕ ਸੇਵਾ ਖਾਤੇ ਦੇ ਅਧੀਨ ਜਾਂਦੀ ਸੀ ਅਤੇ ਖਾਸ ਮੁਹਿੰਮ IDs ਲਈ ਅੰਕੜੇ ਡਾਊਨਲੋਡ ਕੀਤੇ ਜਾਂਦੇ ਸਨ। ਇਹੀ ਗੱਲ ਵਿਗਿਆਪਨ ਪ੍ਰਣਾਲੀਆਂ ਨਾਲ ਵਾਪਰੀ।

ਡਾਉਨਲੋਡ ਕੀਤਾ ਡੇਟਾ ਇੱਕ ਛੋਟੇ ਕਸਟਮ ਡੈਸ਼ਬੋਰਡ ਦੇ ਰੂਪ ਵਿੱਚ ਇੰਟਰਫੇਸ ਤੇ ਪ੍ਰਦਰਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਸੀ:

ਸਾਡੇ ਲਈ ਅਚਾਨਕ, MVP ਨੇ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ ਅਤੇ ਇੰਟਰਨੈੱਟ 'ਤੇ ਵਿਗਿਆਪਨ ਮੁਹਿੰਮਾਂ ਦੇ ਮੌਜੂਦਾ ਅੰਕੜਿਆਂ ਨੂੰ ਡਾਊਨਲੋਡ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ। ਅਸੀਂ ਕਈ ਗਾਹਕਾਂ 'ਤੇ ਸਿਸਟਮ ਨੂੰ ਲਾਗੂ ਕੀਤਾ, ਪਰ ਜਦੋਂ ਸਕੇਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ, ਤਾਂ ਸਾਨੂੰ ਗੰਭੀਰ ਸਮੱਸਿਆਵਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ:

• ਮੁੱਖ ਸਮੱਸਿਆ ਸਿਸਟਮ ਵਿੱਚ ਲੋਡ ਕਰਨ ਲਈ ਡਾਟਾ ਤਿਆਰ ਕਰਨ ਦੀ ਗੁੰਝਲਤਾ ਸੀ। ਨਾਲ ਹੀ, ਪਲੇਸਮੈਂਟ ਡੇਟਾ ਨੂੰ ਲੋਡ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸਖਤ ਨਿਸ਼ਚਤ ਫਾਰਮੈਟ ਵਿੱਚ ਬਦਲਣਾ ਪੈਂਦਾ ਸੀ। ਡਾਊਨਲੋਡ ਫਾਈਲ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਸਾਈਟਾਂ ਤੋਂ ਇਕਾਈ ਪਛਾਣਕਰਤਾਵਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨਾ ਜ਼ਰੂਰੀ ਸੀ। ਸਾਨੂੰ ਇਸ ਤੱਥ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈ ਰਿਹਾ ਹੈ ਕਿ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਅਣਸਿਖਿਅਤ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਇਹ ਸਮਝਾਉਣਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੈ ਕਿ ਸਾਈਟ 'ਤੇ ਇਹ ਪਛਾਣਕਰਤਾ ਕਿੱਥੇ ਲੱਭਣੇ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਫਾਈਲ ਵਿੱਚ ਕਿੱਥੇ ਦਾਖਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਸਾਈਟਾਂ 'ਤੇ ਮੁਹਿੰਮ ਚਲਾ ਰਹੇ ਵਿਭਾਗਾਂ ਵਿੱਚ ਕਰਮਚਾਰੀਆਂ ਦੀ ਗਿਣਤੀ ਅਤੇ ਟਰਨਓਵਰ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਇਸ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਸਾਡੇ ਪਾਸੇ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਸਹਾਇਤਾ ਮਿਲੀ, ਜਿਸ ਤੋਂ ਅਸੀਂ ਬਿਲਕੁਲ ਵੀ ਖੁਸ਼ ਨਹੀਂ ਸੀ।
• ਇੱਕ ਹੋਰ ਸਮੱਸਿਆ ਇਹ ਸੀ ਕਿ ਸਾਰੇ ਵਿਗਿਆਪਨ ਪਲੇਟਫਾਰਮਾਂ ਵਿੱਚ ਹੋਰ ਖਾਤਿਆਂ ਨੂੰ ਵਿਗਿਆਪਨ ਮੁਹਿੰਮਾਂ ਤੱਕ ਪਹੁੰਚ ਸੌਂਪਣ ਲਈ ਵਿਧੀ ਨਹੀਂ ਸੀ। ਪਰ ਭਾਵੇਂ ਇੱਕ ਡੈਲੀਗੇਸ਼ਨ ਵਿਧੀ ਉਪਲਬਧ ਸੀ, ਸਾਰੇ ਵਿਗਿਆਪਨਕਰਤਾ ਤੀਜੀ-ਧਿਰ ਦੇ ਖਾਤਿਆਂ ਤੱਕ ਆਪਣੀਆਂ ਮੁਹਿੰਮਾਂ ਤੱਕ ਪਹੁੰਚ ਦੇਣ ਲਈ ਤਿਆਰ ਨਹੀਂ ਸਨ।
• ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਕਾਰਕ ਇੱਕ ਗੁੱਸਾ ਸੀ ਜੋ ਉਪਭੋਗਤਾਵਾਂ ਵਿੱਚ ਇਸ ਤੱਥ ਦੁਆਰਾ ਪੈਦਾ ਹੋਇਆ ਸੀ ਕਿ ਸਾਰੇ ਯੋਜਨਾਬੱਧ ਸੂਚਕਾਂ ਅਤੇ ਪਲੇਸਮੈਂਟ ਵੇਰਵੇ ਜੋ ਉਹ ਪਹਿਲਾਂ ਹੀ ਸਾਡੇ 1C ਲੇਖਾ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਦਾਖਲ ਹੁੰਦੇ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਦੁਬਾਰਾ ਦਾਖਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਡੈਨਬੋ.

ਇਸ ਨੇ ਸਾਨੂੰ ਇਹ ਵਿਚਾਰ ਦਿੱਤਾ ਕਿ ਪਲੇਸਮੈਂਟ ਬਾਰੇ ਜਾਣਕਾਰੀ ਦਾ ਪ੍ਰਾਇਮਰੀ ਸਰੋਤ ਸਾਡਾ 1C ਸਿਸਟਮ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਸਾਰਾ ਡਾਟਾ ਸਹੀ ਅਤੇ ਸਮੇਂ 'ਤੇ ਦਾਖਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਇੱਥੇ ਬਿੰਦੂ ਇਹ ਹੈ ਕਿ ਇਨਵੌਇਸ 1C ਡੇਟਾ ਦੇ ਅਧਾਰ ਤੇ ਤਿਆਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਇਸਲਈ 1C ਵਿੱਚ ਡੇਟਾ ਦੀ ਸਹੀ ਐਂਟਰੀ ਹਰ ਇੱਕ KPI ਲਈ ਇੱਕ ਤਰਜੀਹ ਹੈ)। ਇਸ ਤਰ੍ਹਾਂ ਸਿਸਟਮ ਦਾ ਇੱਕ ਨਵਾਂ ਸੰਕਲਪ ਉਭਰਿਆ ...

ਸੰਕਲਪ

ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਜੋ ਅਸੀਂ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਉਹ ਸੀ ਇੰਟਰਨੈੱਟ 'ਤੇ ਵਿਗਿਆਪਨ ਮੁਹਿੰਮਾਂ ਦੇ ਅੰਕੜੇ ਇਕੱਠੇ ਕਰਨ ਲਈ ਸਿਸਟਮ ਨੂੰ ਇੱਕ ਵੱਖਰੇ ਉਤਪਾਦ ਵਿੱਚ ਵੱਖ ਕਰਨਾ - D1.ਡਿਜੀਟਲ.

ਨਵੀਂ ਧਾਰਨਾ ਵਿੱਚ, ਅਸੀਂ ਲੋਡ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ D1.ਡਿਜੀਟਲ 1C ਤੋਂ ਉਹਨਾਂ ਦੇ ਅੰਦਰ ਵਿਗਿਆਪਨ ਮੁਹਿੰਮਾਂ ਅਤੇ ਪਲੇਸਮੈਂਟਾਂ ਬਾਰੇ ਜਾਣਕਾਰੀ, ਅਤੇ ਫਿਰ ਇਹਨਾਂ ਪਲੇਸਮੈਂਟਾਂ ਲਈ ਸਾਈਟਾਂ ਅਤੇ ਐਡਸਰਵਿੰਗ ਸਿਸਟਮਾਂ ਤੋਂ ਅੰਕੜੇ ਖਿੱਚੋ। ਇਹ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਜੀਵਨ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਸਰਲ ਬਣਾਉਣਾ ਸੀ (ਅਤੇ, ਆਮ ਵਾਂਗ, ਡਿਵੈਲਪਰਾਂ ਲਈ ਹੋਰ ਕੰਮ ਸ਼ਾਮਲ ਕਰਨਾ) ਅਤੇ ਸਹਾਇਤਾ ਦੀ ਮਾਤਰਾ ਨੂੰ ਘਟਾਉਣਾ ਸੀ।

ਪਹਿਲੀ ਸਮੱਸਿਆ ਜਿਸ ਦਾ ਅਸੀਂ ਸਾਹਮਣਾ ਕੀਤਾ ਉਹ ਇੱਕ ਸੰਗਠਨਾਤਮਕ ਪ੍ਰਕਿਰਤੀ ਦੀ ਸੀ ਅਤੇ ਇਸ ਤੱਥ ਨਾਲ ਸਬੰਧਤ ਸੀ ਕਿ ਅਸੀਂ ਇੱਕ ਕੁੰਜੀ ਜਾਂ ਚਿੰਨ੍ਹ ਨਹੀਂ ਲੱਭ ਸਕੇ ਜਿਸ ਦੁਆਰਾ ਅਸੀਂ 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 ਦੁਆਰਾ ਇੱਕ ਟੋਕਨ ਪ੍ਰਾਪਤ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ ਕਿਉਂਕਿ, ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਲਿਖਿਆ ਹੈ, ਸਾਈਟ 'ਤੇ ਲੋੜੀਂਦੇ ਖਾਤੇ ਤੱਕ ਪਹੁੰਚ ਸੌਂਪਣਾ ਹਮੇਸ਼ਾ ਸੰਭਵ ਨਹੀਂ ਹੁੰਦਾ ਹੈ।

ਸਾਈਟਾਂ ਤੋਂ ਇੱਕ ਖਾਤਾ ਚੁਣਨ ਲਈ ਇੱਕ ਯੂਨੀਵਰਸਲ ਮਕੈਨਿਜ਼ਮ ਬਣਾਉਣ ਲਈ, ਸਾਨੂੰ ਕਨੈਕਟਰ API ਵਿੱਚ ਇੱਕ ਢੰਗ ਜੋੜਨਾ ਪਿਆ ਜੋ JSON ਸਕੀਮਾ ਨੂੰ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਜੋ ਇੱਕ ਸੋਧੇ ਹੋਏ JSONEditor ਕੰਪੋਨੈਂਟ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਫਾਰਮ ਵਿੱਚ ਪੇਸ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ, ਉਪਭੋਗਤਾ ਉਹਨਾਂ ਖਾਤਿਆਂ ਦੀ ਚੋਣ ਕਰਨ ਦੇ ਯੋਗ ਸਨ ਜਿੱਥੋਂ ਡੇਟਾ ਡਾਊਨਲੋਡ ਕਰਨਾ ਹੈ।

ਸਾਈਟਾਂ 'ਤੇ ਮੌਜੂਦ ਬੇਨਤੀ ਸੀਮਾਵਾਂ ਦੀ ਪਾਲਣਾ ਕਰਨ ਲਈ, ਅਸੀਂ ਇੱਕ ਟੋਕਨ ਦੇ ਅੰਦਰ ਸੈਟਿੰਗਾਂ ਲਈ ਬੇਨਤੀਆਂ ਨੂੰ ਜੋੜਦੇ ਹਾਂ, ਪਰ ਅਸੀਂ ਸਮਾਨਾਂਤਰ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਟੋਕਨਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰ ਸਕਦੇ ਹਾਂ।

ਅਸੀਂ ਵੈਬ ਐਪਲੀਕੇਸ਼ਨ ਅਤੇ ਕਨੈਕਟਰਾਂ ਦੋਵਾਂ ਲਈ ਲੋਡ ਕੀਤੇ ਡੇਟਾ ਲਈ ਇੱਕ ਸਟੋਰੇਜ ਵਜੋਂ MongoDB ਨੂੰ ਚੁਣਿਆ, ਜਿਸ ਨਾਲ ਸਾਨੂੰ ਵਿਕਾਸ ਦੇ ਸ਼ੁਰੂਆਤੀ ਪੜਾਵਾਂ 'ਤੇ ਡੇਟਾ ਢਾਂਚੇ ਬਾਰੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਚਿੰਤਾ ਨਾ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ ਗਈ, ਜਦੋਂ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਆਬਜੈਕਟ ਮਾਡਲ ਹਰ ਦੂਜੇ ਦਿਨ ਬਦਲਦਾ ਹੈ।

ਸਾਨੂੰ ਜਲਦੀ ਹੀ ਪਤਾ ਲੱਗਾ ਕਿ ਸਾਰਾ ਡਾਟਾ MongoDB ਵਿੱਚ ਠੀਕ ਤਰ੍ਹਾਂ ਫਿੱਟ ਨਹੀਂ ਬੈਠਦਾ ਹੈ ਅਤੇ, ਉਦਾਹਰਨ ਲਈ, ਰੋਜ਼ਾਨਾ ਅੰਕੜਿਆਂ ਨੂੰ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਟੋਰ ਕਰਨਾ ਵਧੇਰੇ ਸੁਵਿਧਾਜਨਕ ਹੈ। ਇਸਲਈ, ਉਹਨਾਂ ਕੁਨੈਕਟਰਾਂ ਲਈ ਜਿਹਨਾਂ ਦਾ ਡੇਟਾ ਢਾਂਚਾ ਇੱਕ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਲਈ ਵਧੇਰੇ ਢੁਕਵਾਂ ਹੈ, ਅਸੀਂ ਸਟੋਰੇਜ ਦੇ ਤੌਰ 'ਤੇ PostgreSQL ਜਾਂ MS SQL ਸਰਵਰ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੀ ਹੈ।

ਚੁਣੇ ਹੋਏ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਤਕਨਾਲੋਜੀਆਂ ਨੇ ਸਾਨੂੰ D1.Digital ਉਤਪਾਦ ਨੂੰ ਮੁਕਾਬਲਤਨ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਣ ਅਤੇ ਲਾਂਚ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ। ਉਤਪਾਦ ਦੇ ਵਿਕਾਸ ਦੇ ਦੋ ਸਾਲਾਂ ਵਿੱਚ, ਅਸੀਂ ਸਾਈਟਾਂ ਨਾਲ 23 ਕਨੈਕਟਰ ਵਿਕਸਤ ਕੀਤੇ, ਤੀਜੀ-ਧਿਰ APIs ਨਾਲ ਕੰਮ ਕਰਨ ਦਾ ਅਨਮੋਲ ਤਜਰਬਾ ਹਾਸਲ ਕੀਤਾ, ਵੱਖ-ਵੱਖ ਸਾਈਟਾਂ ਦੇ ਨੁਕਸਾਨਾਂ ਤੋਂ ਬਚਣਾ ਸਿੱਖਿਆ, ਜੋ ਹਰੇਕ ਦੀ ਆਪਣੀ ਸੀ, ਘੱਟੋ-ਘੱਟ 3 ਦੇ API ਦੇ ਵਿਕਾਸ ਵਿੱਚ ਯੋਗਦਾਨ ਪਾਇਆ। ਸਾਈਟਾਂ, ਲਗਭਗ 15 ਮੁਹਿੰਮਾਂ ਅਤੇ 000 ਤੋਂ ਵੱਧ ਪਲੇਸਮੈਂਟਾਂ ਲਈ ਸਵੈਚਲਿਤ ਤੌਰ 'ਤੇ ਡਾਉਨਲੋਡ ਕੀਤੀ ਜਾਣਕਾਰੀ, ਉਤਪਾਦ ਦੇ ਸੰਚਾਲਨ 'ਤੇ ਉਪਭੋਗਤਾਵਾਂ ਤੋਂ ਬਹੁਤ ਸਾਰੇ ਫੀਡਬੈਕ ਇਕੱਤਰ ਕਰਦੇ ਹਨ ਅਤੇ ਇਸ ਫੀਡਬੈਕ ਦੇ ਅਧਾਰ 'ਤੇ, ਉਤਪਾਦ ਦੀ ਮੁੱਖ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਕਈ ਵਾਰ ਬਦਲਣ ਵਿੱਚ ਕਾਮਯਾਬ ਹੁੰਦੇ ਹਨ।

ਹੱਲ ਆਰਕੀਟੈਕਚਰ 2.0

ਵਿਕਾਸ ਸ਼ੁਰੂ ਹੋਏ ਦੋ ਸਾਲ ਬੀਤ ਚੁੱਕੇ ਹਨ D1.ਡਿਜੀਟਲ. ਸਿਸਟਮ ਉੱਤੇ ਲੋਡ ਵਿੱਚ ਲਗਾਤਾਰ ਵਾਧਾ ਅਤੇ ਵੱਧ ਤੋਂ ਵੱਧ ਨਵੇਂ ਡੇਟਾ ਸਰੋਤਾਂ ਦੇ ਉਭਾਰ ਨੇ ਹੌਲੀ-ਹੌਲੀ ਮੌਜੂਦਾ ਹੱਲ ਢਾਂਚੇ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਦਾ ਖੁਲਾਸਾ ਕੀਤਾ।

ਪਹਿਲੀ ਸਮੱਸਿਆ ਸਾਈਟਾਂ ਤੋਂ ਡਾਉਨਲੋਡ ਕੀਤੇ ਗਏ ਡੇਟਾ ਦੀ ਮਾਤਰਾ ਨਾਲ ਸਬੰਧਤ ਹੈ. ਸਾਨੂੰ ਇਸ ਤੱਥ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ ਕਿ ਸਭ ਤੋਂ ਵੱਡੀਆਂ ਸਾਈਟਾਂ ਤੋਂ ਸਾਰੇ ਲੋੜੀਂਦੇ ਡੇਟਾ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਅਤੇ ਅੱਪਡੇਟ ਕਰਨ ਵਿੱਚ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੱਗ ਗਿਆ। ਉਦਾਹਰਨ ਲਈ, AdRiver ਵਿਗਿਆਪਨ ਪ੍ਰਣਾਲੀ ਤੋਂ ਡਾਟਾ ਇਕੱਠਾ ਕਰਨਾ, ਜਿਸ ਨਾਲ ਅਸੀਂ ਜ਼ਿਆਦਾਤਰ ਪਲੇਸਮੈਂਟਾਂ ਲਈ ਅੰਕੜੇ ਟ੍ਰੈਕ ਕਰਦੇ ਹਾਂ, ਲਗਭਗ 12 ਘੰਟੇ ਲੱਗਦੇ ਹਨ।

ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, ਅਸੀਂ ਸਾਈਟਾਂ ਤੋਂ ਡੇਟਾ ਨੂੰ ਡਾਊਨਲੋਡ ਕਰਨ ਲਈ ਹਰ ਤਰ੍ਹਾਂ ਦੀਆਂ ਰਿਪੋਰਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੀ ਹੈ, ਅਸੀਂ ਸਾਈਟਾਂ ਦੇ ਨਾਲ ਮਿਲ ਕੇ ਉਹਨਾਂ ਦੇ API ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਾਂ ਤਾਂ ਜੋ ਇਸ ਦੇ ਸੰਚਾਲਨ ਦੀ ਗਤੀ ਸਾਡੀਆਂ ਲੋੜਾਂ ਨੂੰ ਪੂਰਾ ਕਰ ਸਕੇ, ਅਤੇ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਡਾਟਾ ਡਾਊਨਲੋਡ ਨੂੰ ਸਮਾਨਾਂਤਰ ਬਣਾਇਆ ਜਾ ਸਕੇ।

ਇੱਕ ਹੋਰ ਸਮੱਸਿਆ ਡਾਉਨਲੋਡ ਕੀਤੇ ਡੇਟਾ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨਾਲ ਸਬੰਧਤ ਹੈ। ਹੁਣ, ਜਦੋਂ ਨਵੇਂ ਪਲੇਸਮੈਂਟ ਅੰਕੜੇ ਆਉਂਦੇ ਹਨ, ਮੈਟ੍ਰਿਕਸ ਦੀ ਮੁੜ ਗਣਨਾ ਕਰਨ ਦੀ ਇੱਕ ਬਹੁ-ਪੜਾਵੀ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ ਕੱਚਾ ਡੇਟਾ ਲੋਡ ਕਰਨਾ, ਹਰੇਕ ਸਾਈਟ ਲਈ ਇਕੱਤਰ ਕੀਤੇ ਮੈਟ੍ਰਿਕਸ ਦੀ ਗਣਨਾ ਕਰਨਾ, ਵੱਖ-ਵੱਖ ਸਰੋਤਾਂ ਤੋਂ ਡੇਟਾ ਦੀ ਇੱਕ ਦੂਜੇ ਨਾਲ ਤੁਲਨਾ ਕਰਨਾ, ਅਤੇ ਮੁਹਿੰਮ ਲਈ ਸੰਖੇਪ ਮੈਟ੍ਰਿਕਸ ਦੀ ਗਣਨਾ ਕਰਨਾ ਸ਼ਾਮਲ ਹੈ। ਇਸ ਨਾਲ ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨ 'ਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਲੋਡ ਹੁੰਦਾ ਹੈ ਜੋ ਸਾਰੀਆਂ ਗਣਨਾਵਾਂ ਕਰਦਾ ਹੈ। ਕਈ ਵਾਰ, ਮੁੜ ਗਣਨਾ ਪ੍ਰਕਿਰਿਆ ਦੇ ਦੌਰਾਨ, ਐਪਲੀਕੇਸ਼ਨ ਨੇ ਸਰਵਰ 'ਤੇ ਸਾਰੀ ਮੈਮੋਰੀ, ਲਗਭਗ 10-15 GB ਦੀ ਖਪਤ ਕੀਤੀ, ਜਿਸਦਾ ਸਿਸਟਮ ਨਾਲ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਕੰਮ 'ਤੇ ਸਭ ਤੋਂ ਵੱਧ ਨੁਕਸਾਨਦੇਹ ਪ੍ਰਭਾਵ ਪਿਆ।

ਉਤਪਾਦ ਦੇ ਹੋਰ ਵਿਕਾਸ ਲਈ ਪਛਾਣੀਆਂ ਗਈਆਂ ਸਮੱਸਿਆਵਾਂ ਅਤੇ ਅਭਿਲਾਸ਼ੀ ਯੋਜਨਾਵਾਂ ਨੇ ਸਾਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਆਰਕੀਟੈਕਚਰ 'ਤੇ ਮੁੜ ਵਿਚਾਰ ਕਰਨ ਦੀ ਲੋੜ ਵੱਲ ਅਗਵਾਈ ਕੀਤੀ।

ਅਸੀਂ ਕਨੈਕਟਰਾਂ ਨਾਲ ਸ਼ੁਰੂਆਤ ਕੀਤੀ।
ਅਸੀਂ ਦੇਖਿਆ ਕਿ ਸਾਰੇ ਕਨੈਕਟਰ ਇੱਕੋ ਮਾਡਲ ਦੇ ਅਨੁਸਾਰ ਕੰਮ ਕਰਦੇ ਹਨ, ਇਸਲਈ ਅਸੀਂ ਇੱਕ ਪਾਈਪਲਾਈਨ ਫਰੇਮਵਰਕ ਬਣਾਇਆ ਹੈ ਜਿਸ ਵਿੱਚ ਇੱਕ ਕਨੈਕਟਰ ਬਣਾਉਣ ਲਈ ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਕਦਮਾਂ ਦੇ ਤਰਕ ਨੂੰ ਪ੍ਰੋਗ੍ਰਾਮ ਕਰਨਾ ਪੈਂਦਾ ਸੀ, ਬਾਕੀ ਸਰਵ ਵਿਆਪਕ ਸੀ। ਜੇਕਰ ਕਿਸੇ ਕਨੈਕਟਰ ਨੂੰ ਸੁਧਾਰ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਅਸੀਂ ਤੁਰੰਤ ਇਸਨੂੰ ਉਸੇ ਸਮੇਂ ਇੱਕ ਨਵੇਂ ਫਰੇਮਵਰਕ ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕਰਦੇ ਹਾਂ ਜਦੋਂ ਕਨੈਕਟਰ ਵਿੱਚ ਸੁਧਾਰ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ।

ਉਸੇ ਸਮੇਂ, ਅਸੀਂ ਡੌਕਰ ਅਤੇ ਕੁਬਰਨੇਟਸ ਲਈ ਕਨੈਕਟਰਾਂ ਨੂੰ ਤੈਨਾਤ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ।
ਅਸੀਂ ਕਾਫ਼ੀ ਲੰਬੇ ਸਮੇਂ ਲਈ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਜਾਣ ਦੀ ਯੋਜਨਾ ਬਣਾਈ, ਸੀਆਈ/ਸੀਡੀ ਸੈਟਿੰਗਾਂ ਨਾਲ ਪ੍ਰਯੋਗ ਕੀਤਾ, ਪਰ ਉਦੋਂ ਹੀ ਚਲਣਾ ਸ਼ੁਰੂ ਕੀਤਾ ਜਦੋਂ ਇੱਕ ਕਨੈਕਟਰ, ਇੱਕ ਗਲਤੀ ਦੇ ਕਾਰਨ, ਸਰਵਰ ਉੱਤੇ 20 GB ਤੋਂ ਵੱਧ ਮੈਮੋਰੀ ਨੂੰ ਖਾਣ ਲੱਗ ਪਿਆ, ਅਮਲੀ ਤੌਰ 'ਤੇ ਹੋਰ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਖਤਮ ਕਰ ਦਿੱਤਾ। . ਜਾਂਚ ਦੇ ਦੌਰਾਨ, ਕਨੈਕਟਰ ਨੂੰ ਇੱਕ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਵਿੱਚ ਭੇਜਿਆ ਗਿਆ ਸੀ, ਜਿੱਥੇ ਇਹ ਆਖਰਕਾਰ ਰਹਿ ਗਿਆ, ਭਾਵੇਂ ਗਲਤੀ ਠੀਕ ਹੋਣ ਤੋਂ ਬਾਅਦ ਵੀ।

ਬਹੁਤ ਜਲਦੀ ਅਸੀਂ ਮਹਿਸੂਸ ਕੀਤਾ ਕਿ ਕੁਬਰਨੇਟਸ ਸੁਵਿਧਾਜਨਕ ਸੀ, ਅਤੇ ਛੇ ਮਹੀਨਿਆਂ ਦੇ ਅੰਦਰ ਅਸੀਂ 7 ਕਨੈਕਟਰ ਅਤੇ ਕਨੈਕਟਰ ਪ੍ਰੌਕਸੀ, ਜੋ ਸਭ ਤੋਂ ਵੱਧ ਸਰੋਤਾਂ ਦੀ ਖਪਤ ਕਰਦੇ ਹਨ, ਨੂੰ ਉਤਪਾਦਨ ਕਲੱਸਟਰ ਵਿੱਚ ਤਬਦੀਲ ਕਰ ਦਿੱਤਾ।

ਕਨੈਕਟਰਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਬਾਕੀ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਬਦਲਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ।
ਮੁੱਖ ਸਮੱਸਿਆ ਇਹ ਸੀ ਕਿ ਡੇਟਾ ਵੱਡੇ ਬੈਚਾਂ ਵਿੱਚ ਕਨੈਕਟਰਾਂ ਤੋਂ ਪ੍ਰੌਕਸੀ ਤੱਕ ਆਉਂਦਾ ਹੈ, ਅਤੇ ਫਿਰ DANBoID ਨੂੰ ਹਿੱਟ ਕਰਦਾ ਹੈ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਲਈ ਕੇਂਦਰੀ ਵੈਬ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ। ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਮੈਟ੍ਰਿਕਸ ਪੁਨਰਗਣਨਾ ਦੇ ਕਾਰਨ, ਐਪਲੀਕੇਸ਼ਨ 'ਤੇ ਇੱਕ ਵੱਡਾ ਬੋਝ ਹੈ।

ਵਿਅਕਤੀਗਤ ਡਾਟਾ ਇਕੱਠਾ ਕਰਨ ਵਾਲੀਆਂ ਨੌਕਰੀਆਂ ਦੀ ਸਥਿਤੀ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨਾ ਅਤੇ ਕੇਂਦਰੀ ਵੈਬ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਕਨੈਕਟਰਾਂ ਦੇ ਅੰਦਰ ਹੋਣ ਵਾਲੀਆਂ ਗਲਤੀਆਂ ਦੀ ਰਿਪੋਰਟ ਕਰਨਾ ਵੀ ਕਾਫ਼ੀ ਮੁਸ਼ਕਲ ਸਾਬਤ ਹੋਇਆ ਹੈ ਤਾਂ ਜੋ ਉਪਭੋਗਤਾ ਇਹ ਦੇਖ ਸਕਣ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਹੈ ਅਤੇ ਡੇਟਾ ਕਿਉਂ ਇਕੱਤਰ ਨਹੀਂ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ।

ਇਹਨਾਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, ਅਸੀਂ ਆਰਕੀਟੈਕਚਰ 2.0 ਵਿਕਸਿਤ ਕੀਤਾ ਹੈ।

ਆਰਕੀਟੈਕਚਰ ਦੇ ਨਵੇਂ ਸੰਸਕਰਣ ਵਿੱਚ ਮੁੱਖ ਅੰਤਰ ਇਹ ਹੈ ਕਿ ਵੈੱਬ API ਦੀ ਬਜਾਏ, ਅਸੀਂ ਸੇਵਾਵਾਂ ਦੇ ਵਿਚਕਾਰ ਸੰਦੇਸ਼ਾਂ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ RabbitMQ ਅਤੇ MassTransit ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। ਅਜਿਹਾ ਕਰਨ ਲਈ, ਸਾਨੂੰ ਲਗਭਗ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕਨੈਕਟਰ ਪ੍ਰੌਕਸੀ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣਾ ਪਿਆ, ਇਸ ਨੂੰ ਕਨੈਕਟਰ ਹੱਬ ਬਣਾਉਣਾ। ਨਾਮ ਬਦਲਿਆ ਗਿਆ ਸੀ ਕਿਉਂਕਿ ਸੇਵਾ ਦੀ ਮੁੱਖ ਭੂਮਿਕਾ ਹੁਣ ਕਨੈਕਟਰਾਂ ਅਤੇ ਪਿੱਛੇ ਬੇਨਤੀਆਂ ਨੂੰ ਅੱਗੇ ਭੇਜਣ ਵਿੱਚ ਨਹੀਂ ਹੈ, ਪਰ ਕਨੈਕਟਰਾਂ ਤੋਂ ਮੈਟ੍ਰਿਕਸ ਦੇ ਸੰਗ੍ਰਹਿ ਦੇ ਪ੍ਰਬੰਧਨ ਵਿੱਚ ਹੈ।

ਕੇਂਦਰੀ ਵੈਬ ਐਪਲੀਕੇਸ਼ਨ ਤੋਂ, ਅਸੀਂ ਸਾਈਟਾਂ ਤੋਂ ਪਲੇਸਮੈਂਟ ਅਤੇ ਅੰਕੜਿਆਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਨੂੰ ਵੱਖਰੀਆਂ ਸੇਵਾਵਾਂ ਵਿੱਚ ਵੱਖ ਕੀਤਾ ਹੈ, ਜਿਸ ਨਾਲ ਬੇਲੋੜੀਆਂ ਪੁਨਰ-ਗਣਨਾਵਾਂ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾਉਣਾ ਅਤੇ ਪਲੇਸਮੈਂਟ ਪੱਧਰ 'ਤੇ ਸਿਰਫ਼ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਗਣਨਾ ਕੀਤੇ ਅਤੇ ਇਕੱਠੇ ਕੀਤੇ ਅੰਕੜਿਆਂ ਨੂੰ ਸਟੋਰ ਕਰਨਾ ਸੰਭਵ ਹੋ ਗਿਆ ਹੈ। ਅਸੀਂ ਕੱਚੇ ਡੇਟਾ ਦੇ ਅਧਾਰ 'ਤੇ ਮੂਲ ਅੰਕੜਿਆਂ ਦੀ ਗਣਨਾ ਕਰਨ ਲਈ ਤਰਕ ਨੂੰ ਮੁੜ ਲਿਖਿਆ ਅਤੇ ਅਨੁਕੂਲ ਬਣਾਇਆ ਹੈ।

ਇਸਦੇ ਨਾਲ ਹੀ, ਅਸੀਂ ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਡੌਕਰ ਅਤੇ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਮਾਈਗਰੇਟ ਕਰ ਰਹੇ ਹਾਂ ਤਾਂ ਜੋ ਹੱਲ ਨੂੰ ਸਕੇਲ ਵਿੱਚ ਆਸਾਨ ਅਤੇ ਪ੍ਰਬੰਧਨ ਲਈ ਵਧੇਰੇ ਸੁਵਿਧਾਜਨਕ ਬਣਾਇਆ ਜਾ ਸਕੇ।

ਹੁਣ ਅਸੀ ਕਿੱਥੇ ਹਾਂ

ਸੰਕਲਪ ਦਾ ਸਬੂਤ ਆਰਕੀਟੈਕਚਰ 2.0 ਉਤਪਾਦ D1.ਡਿਜੀਟਲ ਕਨੈਕਟਰਾਂ ਦੇ ਸੀਮਤ ਸਮੂਹ ਦੇ ਨਾਲ ਇੱਕ ਟੈਸਟ ਵਾਤਾਵਰਨ ਵਿੱਚ ਤਿਆਰ ਅਤੇ ਕੰਮ ਕਰਨਾ। ਬੱਸ ਇਹ ਕਰਨਾ ਬਾਕੀ ਹੈ ਕਿ ਇੱਕ ਨਵੇਂ ਪਲੇਟਫਾਰਮ 'ਤੇ ਹੋਰ 20 ਕਨੈਕਟਰਾਂ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣਾ, ਟੈਸਟ ਕਰਨਾ ਕਿ ਡੇਟਾ ਸਹੀ ਤਰ੍ਹਾਂ ਲੋਡ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਸਾਰੇ ਮੈਟ੍ਰਿਕਸ ਦੀ ਸਹੀ ਗਣਨਾ ਕੀਤੀ ਗਈ ਹੈ, ਅਤੇ ਪੂਰੇ ਡਿਜ਼ਾਈਨ ਨੂੰ ਉਤਪਾਦਨ ਵਿੱਚ ਰੋਲ ਆਊਟ ਕਰਨਾ ਹੈ।

ਵਾਸਤਵ ਵਿੱਚ, ਇਹ ਪ੍ਰਕਿਰਿਆ ਹੌਲੀ-ਹੌਲੀ ਵਾਪਰੇਗੀ ਅਤੇ ਸਾਨੂੰ ਸਭ ਕੁਝ ਕੰਮ ਕਰਨ ਲਈ ਪੁਰਾਣੇ APIs ਦੇ ਨਾਲ ਬੈਕਵਰਡ ਅਨੁਕੂਲਤਾ ਛੱਡਣੀ ਪਵੇਗੀ.

ਸਾਡੀਆਂ ਤਤਕਾਲ ਯੋਜਨਾਵਾਂ ਵਿੱਚ ਨਵੇਂ ਕਨੈਕਟਰਾਂ ਦਾ ਵਿਕਾਸ, ਨਵੇਂ ਸਿਸਟਮਾਂ ਨਾਲ ਏਕੀਕਰਣ ਅਤੇ ਜੁੜੀਆਂ ਸਾਈਟਾਂ ਅਤੇ ਵਿਗਿਆਪਨ ਪ੍ਰਣਾਲੀਆਂ ਤੋਂ ਡਾਉਨਲੋਡ ਕੀਤੇ ਗਏ ਡੇਟਾ ਦੇ ਸੈੱਟ ਵਿੱਚ ਵਾਧੂ ਮੈਟ੍ਰਿਕਸ ਸ਼ਾਮਲ ਕਰਨਾ ਸ਼ਾਮਲ ਹੈ।

ਅਸੀਂ ਕੇਂਦਰੀ ਵੈਬ ਐਪਲੀਕੇਸ਼ਨ ਸਮੇਤ ਸਾਰੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਡੌਕਰ ਅਤੇ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕਰਨ ਦੀ ਵੀ ਯੋਜਨਾ ਬਣਾ ਰਹੇ ਹਾਂ। ਨਵੇਂ ਆਰਕੀਟੈਕਚਰ ਦੇ ਨਾਲ ਮਿਲਾ ਕੇ, ਇਹ ਖਪਤ ਕੀਤੇ ਸਰੋਤਾਂ ਦੀ ਤੈਨਾਤੀ, ਨਿਗਰਾਨੀ ਅਤੇ ਨਿਯੰਤਰਣ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਸਰਲ ਬਣਾ ਦੇਵੇਗਾ।

ਇੱਕ ਹੋਰ ਵਿਚਾਰ ਅੰਕੜਿਆਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ ਡੇਟਾਬੇਸ ਦੀ ਚੋਣ ਨਾਲ ਪ੍ਰਯੋਗ ਕਰਨਾ ਹੈ, ਜੋ ਇਸ ਸਮੇਂ ਮੋਂਗੋਡੀਬੀ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਗਿਆ ਹੈ। ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਕਈ ਨਵੇਂ ਕਨੈਕਟਰਾਂ ਨੂੰ SQL ਡੇਟਾਬੇਸ ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕਰ ਚੁੱਕੇ ਹਾਂ, ਪਰ ਉੱਥੇ ਇਹ ਅੰਤਰ ਲਗਭਗ ਧਿਆਨ ਦੇਣ ਯੋਗ ਨਹੀਂ ਹੈ, ਅਤੇ ਦਿਨ ਦੇ ਹਿਸਾਬ ਨਾਲ ਇਕੱਠੇ ਕੀਤੇ ਅੰਕੜਿਆਂ ਲਈ, ਜੋ ਇੱਕ ਮਨਮਾਨੇ ਸਮੇਂ ਲਈ ਬੇਨਤੀ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਲਾਭ ਕਾਫ਼ੀ ਗੰਭੀਰ ਹੋ ਸਕਦਾ ਹੈ।

ਆਮ ਤੌਰ 'ਤੇ, ਯੋਜਨਾਵਾਂ ਸ਼ਾਨਦਾਰ ਹਨ, ਆਓ ਅੱਗੇ ਵਧੀਏ :)

ਲੇਖ ਦੇ ਲੇਖਕ R&D Dentsu Aegis Network ਰੂਸ: ਜਾਰਜੀ ਓਸਟਾਪੇਂਕੋ (ਸ਼ਮੀਗਾ), ਮਿਖਾਇਲ ਕੋਟਸਿਕ (hitexx)

ਸਰੋਤ: www.habr.com