Voluum, RedTrack ਅਤੇ Keitaro ਵਿੱਚ ਸਰਵਰ-ਸਾਈਡ ਟ੍ਰੈਕਿੰਗ

ਕਦਮ ੧: ਸੈਟਿੰਗਜ਼ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਇਵੈਂਟ ਪਾਈਪਲਾਈਨ ਨਕਸ਼ੇ ‘ਤੇ ਲਾਓ

ਨਤੀਜਾ: ਤੁਸੀਂ ਜਾਣੋਂਗੇ ਕਿ ਕਿਹੜੇ ਪਛਾਣਕਰਤਾ ਐਡ ਪਲੇਟਫਾਰਮ ਤੋਂ ਟ੍ਰੈਕਰ, ਟ੍ਰੈਕਰ ਤੋਂ ਨੈੱਟਵਰਕ ਅਤੇ ਟ੍ਰੈਕਰ ਤੋਂ ਮੁੜ ਐਡ ਪਲੇਟਫਾਰਮ API ਤੱਕ ਜਾਂਦੇ ਹਨ।

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

ਲੋੜੀਂਦੇ ਆਈਡੀ ਪਰਿਭਾਸ਼ਤ ਕਰੋ

ਘੱਟੋ-ਘੱਟ ਇੱਕ ਪਲੇਟਫਾਰਮ ਕਲਿੱਕ ਪਛਾਣਕਰਤਾ, ਇੱਕ ਟ੍ਰੈਕਰ ਕਲਿੱਕ ਪਛਾਣਕਰਤਾ ਅਤੇ ਇੱਕ ਨੈੱਟਵਰਕ ਲੈਣ-ਦੇਣ ਪਛਾਣਕਰਤਾ ਬਚਾਓ। Meta ਲਈ, ਇਸ ਵਿੱਚ fbclid ਜਾਂ ਇਵੈਂਟ ਮੇਟਾਡਾਟਾ ਹੋ ਸਕਦੇ ਹਨ। Google Ads ਲਈ, ਜਿੱਥੇ ਪ੍ਰਸੰਗਿਕ ਹੋਵੇ ਉੱਥੇ gclid ਹੋ ਸਕਦਾ ਹੈ। ਟ੍ਰੈਕਰ ਲਈ ਮਹੱਤਵਪੂਰਣ ਮੁੱਲ ਇਹ ਹੈ ਕਿ ਨੈੱਟਵਰਕ subid ਜਾਂ clickid ਟੋਕਨ ਵਜੋਂ ਆਫ਼ਰ URL ਨੂੰ ਭੇਜਿਆ ਗਿਆ ਅਦੁੱਤੀ ਕਲਿੱਕ ਆਈਡੀ ਹੈ।

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

ਇਵੈਂਟ ਨਾਂ ਅਤੇ ਮੁੱਲ ਨਿਯਮ ਇਕਸਾਰ ਰੱਖੋ

ਛੋਟਾ ਇਵੈਂਟ ਡਿਕਸ਼ਨਰੀ ਵਰਤੋ। ਉਦਾਹਰਨ ਵਜੋਂ, lead, trial_start, purchase ਅਤੇ rebill ਦਾ ਹਰੇਕ ਦਾ ਇੱਕ ਹੀ ਦਰਜ ਕੀਤਾ ਅਰਥ ਹੋਵੇ। ਇੱਕ ਨੈੱਟਵਰਕ ਵੱਲੋਂ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਖਰੀਦ ਲਈ sale ਵਰਤਣਾ, ਜਦਕਿ ਦੂਜੇ ਵੱਲੋਂ ਉਸੇ ਲੇਬਲ ਨਾਲ pending ਲੀਡ ਦਰਸਾਉਣਾ ਮੰਨਜ਼ੂਰ ਨਹੀਂ।

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

ਹਕੀਕਤੀ ਸਵੀਕਾਰ ਯੋਗ ਸਮਾਂ-ਖਿੜਕੀਆਂ ਤੈਅ ਕਰੋ

ਇੱਕ ਡਾਇਰੈਕਟ-ਰਿਸਪਾਂਸ ਸੇਲਜ਼ ਪਾਥ ਵਿੱਚ ਅਕਸਰ ਅੰਦਰੂਨੀ ਦਿਨ ਦੀਆਂ ਕਨਵਰਜ਼ਨਾਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ, ਪਰ ਬਿਲਿੰਗ ਵਿੱਚ ਦੇਰੀ, ਕਾਲ ਸੈਂਟਰ ਵੈਰੀਫਿਕੇਸ਼ਨ ਅਤੇ ਰਿਫੰਡ ਖਿੜਕੀਆਂ ਰਿਪੋਰਟਿੰਗ ਲੰਮੀ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਓਪਰੇਟਿੰਗ ਅਨੁਮਾਨ ਵਜੋਂ ਕਈ click-to-conversion ਰਾਹਾਂ ਲਈ ੧ ਤੋਂ ੭ ਦਿਨ ਅਤੇ ਦੇਰੀ ਨਾਲ ਮਨਜ਼ੂਰੀ ਵਾਲੇ ਫਨਲਾਂ ਲਈ ੧੪ ਤੋਂ ੩੦ ਦਿਨ ਮੰਨਿਆ ਜਾ ਸਕਦਾ ਹੈ।

QA ਲਈ ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਕਬੂਲਯੋਗ ਗਲਤੀ-ਸੀਮਾ ਬੈਂਡ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਟ੍ਰੈਕਰ ਕਨਵਰਜ਼ਨ ਅਤੇ ਪਲੇਟਫਾਰਮ-ਰਿਪੋਰਟ ਇਵੈਂਟਾਂ ਵਿਚਕਾਰ ੫-੧੫% ਅਨੁਮਾਨਿਤ ਫਰਕ ਇਜਾਜ਼ਤਯੋਗ ਹੋ ਸਕਦਾ ਹੈ, ਜੋ ਸਹਿਮਤੀ-ਹਾਨੀ, API ਮੈਚਿੰਗ, ਐਟ੍ਰਿਬਿਊਸ਼ਨ ਵਿੰਡੋ ਅਤੇ ਰਿਜੈਕਟ ਹੋਏ ਇਵੈਂਟਾਂ ‘ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਆਮ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਅਚਾਨਕ ਬਦਲਾਅ ਦਿਨ-ਵਾਰ ਇੱਕੱਲੀ ਗਲਤੀ ਨਾਲੋਂ ਬਿਹਤਰ ਸੂਚਕ ਹੁੰਦਾ ਹੈ।

ਕਦਮ ੨: ਭਰੋਸੇਯੋਗ ਪੋਸਟਬੈਕ ਸਮਝੌਤਾ ਬਣਾਓ

ਨਤੀਜਾ: ਨੈੱਟਵਰਕ ਕੇਵਲ ਪੂਰਾ, ਡੀਡੁਪਲੀਕੇਟ ਕੀਤਾ ਕਨਵਰਜ਼ਨ ਡਾਟਾ ਹੀ ਟ੍ਰੈਕਰ ਨੂੰ ਭੇਜੇ।

ਪੋਸਟਬੈਕ URL ਉਹ ਨੈੱਟਵਰਕ-ਟੂ-ਟ੍ਰੈਕਰ ਕਾਲਬੈਕ ਹੈ ਜੋ ਕਲਿੱਕ ਦਾ ਵਪਾਰਕ ਨਤੀਜਾ ਦਰਜ ਕਰਦੀ ਹੈ। CAPI ਫੋਰਵਰਡਿੰਗ ਉਹ ਟ੍ਰੈਕਰ-ਤੋਂ-ਪਲੇਟਫਾਰਮ API ਇਵੈਂਟ ਹੈ ਜੋ ਐਡ ਸਿਸਟਮਾਂ ਨੂੰ ਸਰਵਰ-ਸਾਈਡ ਸਿਗਨਲਾਂ ਤੋਂ ਐਟ੍ਰਿਬਿਊਟ ਅਤੇ ਓਪਟੀਮਾਈਜ਼ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ। ਇਨ੍ਹਾਂ ਨੂੰ ਇੱਕੋ ਪਾਈਪਲਾਈਨ ਦੇ ਦੋ ਵੱਖਰੇ ਪੈਰ ਸਮਝੋ।

ਲੋੜੀਂਦੇ ਪੋਸਟਬੈਕ ਫੀਲਡ

ਜਦੋਂ ਹਰ ਨੈੱਟਵਰਕ ਦੀਆਂ ਟੋਕਨ ਨਾਂਵਾਂ ਵੱਖਰੀਆਂ ਹੋਣ, ਤਦ ਵੀ ਮਿਆਰੀ ਅੰਦਰੂਨੀ ਕੀ ਵਰਤੋ:

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

ਡੀਡੁਪਲੀਕੇਟ ਕਰੋ ਅਤੇ ਸਥਿਤੀ ਬਦਲਾਅ ਸੰਭਾਲੋ

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

ਵਰਤੋਂਯੋਗ ਚੇਤਾਵਨੀ ਵਜੋਂ: ਅਨੁਮਾਨਿਤ ੧-੨% ਤੋਂ ਵੱਧ ਡੁਪਲੀਕੇਟ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਲੈਣ-ਦੇਣ ਆਈਡੀ ਆਮ ਤੌਰ ‘ਤੇ ਦੁਬਾਰਾ ਭੇਜੇ ਗਏ ਪੋਸਟਬੈਕ, ਟੋਕਨ ਮੈਪਿੰਗ ਗਲਤੀਆਂ, ਜਾਂ ਮਨਜ਼ੂਰੀ-ਅਪਡੇਟ ਵਰਕਫਲੋ ਨੂੰ ਨਵੀਂ ਵਿਕਰੀ ਵਜੋਂ ਸਵੀਕਾਰ ਕਰਨ ਦਾ ਸੰਕੇਤ ਹੁੰਦੀ ਹੈ। ਰਿਫੰਡ ਅਤੇ ਚਾਰਜਬੈਕ ਲਈ ਦਰਜ ਕਰੋ ਕਿ ਇਵੈਂਟ ਆਮਦਨੀ ਨੂੰ ਉਲਟਦਾ ਹੈ, ਸਥਿਤੀ ਬਦਲਦਾ ਹੈ ਜਾਂ ਵੱਖਰਾ ਐਡਜਸਟਮੈਂਟ ਇਵੈਂਟ ਬਣਾਂਦਾ ਹੈ।

ਕਾਮਪਲਾਇਅੰਸ ਸੰਦਰਭ ਸੰਭਾਲੋ

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

ਕਦਮ ੩: Voluum ਲਈ S2S ਪੋਸਟਬੈਕ ਅਤੇ CAPI ਫੋਰਵਰਡਿੰਗ ਸੈਟ ਕਰੋ

ਨਤੀਜਾ: Voluum ਨੈੱਟਵਰਕ ਕਨਵਰਜ਼ਨ ਪ੍ਰਾਪਤ ਕਰੇਗਾ, ਆਮਦਨੀ ਸਹੀ ਰੂਪ ਵਿੱਚ ਦਰਜ ਕਰੇਗਾ ਅਤੇ ਕੇਵਲ ਮੈਪ ਕੀਤੇ ਇਵੈਂਟ ਹੀ ਐਡ ਪਲੇਟਫਾਰਮਾਂ ਨੂੰ ਫੋਰਵਰਡ ਕਰੇਗਾ।

Voluum ਅਕਸਰ ਤੇਜ਼ ਚੋਣ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਟੀਮਾਂ ਨੂੰ ਮੈਨੇਜਡ ਟ੍ਰੈਕਿੰਗ, ਮਿਆਰੀ ਮੁਹਿੰਮ ਟੈਮਪਲੇਟ ਅਤੇ ਸਾਫ਼ ਓਪਰੇਸ਼ਨਲ ਰਿਪੋਰਟਿੰਗ ਚਾਹੀਦੀ ਹੈ। ਇਸ ਦੀ ਤਾਕਤ ਸਿਰਫ਼ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਚਾਲੂ ਕਰਨ ‘ਤੇ ਨਹੀਂ, ਬਲਕਿ ਅਨੁਸ਼ਾਸ਼ਿਤ ਟੋਕਨ ਪਾਸ-ਥਰੂ ‘ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ।

Voluum ਕਲਿੱਕ ਆਈਡੀ ਕੈਪਚਰ ਕਰੋ

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

ਫਿਰ ਪੱਕਾ ਕਰੋ ਕਿ ਆਫ਼ਰ URL ਉਹ Voluum ਕਲਿੱਕ ਆਈਡੀ ਨੈੱਟਵਰਕ ਦੇ ਸਵੀਕ੍ਰਿਤ subid ਫੀਲਡ ਵਿੱਚ ਭੇਜਦਾ ਹੈ। ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਵਰਤੇ ਜਾ ਰਹੇ ਉਸੇ ਰੀਡਾਇਰੈਕਟ ਰੂਟ ‘ਤੇ 20-50 ਘੱਟ-ਖਤਰਾ ਟੈਸਟ ਕਲਿੱਕ ਚਲਾਓ। ਇਹ ਓਪਰੇਟਿੰਗ ਅੰਦਾਜ਼ਾ ਹੈ, ਪਰ ਅਕਸਰ ਇਸ ਨਾਲ ਪੈਰਾਮੀਟਰ ਕਟਾਅ, ਗ਼ਲਤ ਮੈਕਰੋ ਜਾਂ ਡਿਵਾਈਸ ਅਨੁਸਾਰ ਵੱਖਰੇ ਵਰਤਾਅ ਕਰਨ ਵਾਲੇ ਰੀਡਾਇਰੈਕਟ ਨਿਯਮ ਸਾਹਮਣੇ ਆ ਜਾਂਦੇ ਹਨ।

ਨੈੱਟਵਰਕ ਪੋਸਟਬੈਕ ਸਹੀ ਢੰਗ ਨਾਲ ਇਨਜੈਸਟ ਕਰੋ

ਲਾਜ਼ਮੀ ਫੀਲਡਾਂ ਵਾਲੇ ਨੈੱਟਵਰਕ ਪੋਸਟਬੈਕ ਐਂਡਪਾਇੰਟ ਸੈਟ ਕਰੋ: ਕਲਿੱਕ ਆਈਡੀ, ਲੈਣ-ਦੇਣ ਆਈਡੀ, ਪੇਆਊਟ, ਕਰੰਸੀ, ਸਥਿਤੀ ਅਤੇ ਟਾਈਮਸਟੈਂਪ। pending, approved, rejected ਅਤੇ refunded ਹਾਲਤਾਂ ਨੂੰ ਉਦੇਸ਼ਪੂਰਵਕ ਮੈਪ ਕਰੋ।

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

Voluum ਇਵੈਂਟ ਪਲੇਟਫਾਰਮ APIs ਨੂੰ ਫੋਰਵਰਡ ਕਰੋ

ਜਦੋਂ Meta Conversions API, Google enhanced conversions ਜਾਂ offline conversion imports, TikTok Events API ਜਾਂ ਸਮਾਨ ਐਂਡਪਾਇੰਟਸ ‘ਤੇ ਫੋਰਵਰਡ ਕਰਦੇ ਹੋ, ਤਾਂ ਹਰ ਨੈੱਟਵਰਕ ਨਤੀਜੇ ਨੂੰ ਇੱਕ ਮੰਜ਼ਿਲ ਇਵੈਂਟ ਵੱਲ ਰਾਹ ਦਿਓ। ਇੱਕ ਪੈਸੇਦਾਰ ਖਰੀਦ ਆਪਣੇ ਆਪ Lead ਅਤੇ Purchase ਦੋਵੇਂ ਨੂੰ ਟ੍ਰਿਗਰ ਨਾ ਕਰੇ, ਜਦ ਤੱਕ ਮੁਹਿੰਮ ਰਣਨੀਤੀ ਸਪਸ਼ਟ ਤੌਰ ‘ਤੇ ਦੋਵੇਂ ਦੀ ਲੋੜ ਨਹੀਂ ਰੱਖਦੀ ਅਤੇ ਡੀਡੁਪਲੀਕੇਸ਼ਨ ਦਰਜ ਨਹੀਂ ਕੀਤਾ ਗਿਆ।

ਹੈਸ਼ ਕੀਤੇ ਯੂਜ਼ਰ ਫੀਲਡ ਸਿਰਫ਼ ਓਥੇ ਹੀ ਵਰਤੋ ਜਿੱਥੇ ਕਾਨੂੰਨੀ ਆਧਾਰ ਅਤੇ ਕਾਫ਼ੀ ਡਾਟਾ ਗੁਣਵੱਤਾ ਮੌਜੂਦ ਹੋਵੇ ਤਾਂ ਕਿ ਮੈਚਿੰਗ ਲਾਭਕਾਰੀ ਬਣੇ। ਪਲੇਟਫਾਰਮ ਦਸਤਾਵੇਜ਼ ਸਮੇਂ ਦੇ ਨਾਲ ਬਦਲਦੇ ਹਨ, ਇਸ ਲਈ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਨੋਟਾਂ ਨੂੰ Meta Conversions API ਅਤੇ Google Ads ਕਨਵਰਜ਼ਨ ਇੰਪੋਰਟ ਵਰਕਫਲੋ ਦੇ ਅਧਿਕਾਰਕ ਹੈਲਪ ਪੰਨਿਆਂ ਨਾਲ ਜੋੜ ਕੇ ਰੱਖੋ।

ਕਦਮ ੪: RedTrack ਲਈ ਮੈਨੇਜਡ ਇਵੈਂਟ ਫੋਰਵਰਡਿੰਗ ਸੈਟ ਕਰੋ

ਨਤੀਜਾ: RedTrack ਪ੍ਰਮਾਣਿਤ ਨੈੱਟਵਰਕ ਪੋਸਟਬੈਕ ਪ੍ਰਾਪਤ ਕਰੇਗਾ ਅਤੇ ਐਡ ਪਲੇਟਫਾਰਮਾਂ ਨੂੰ ਸਥਿਰ ਸਰਵਰ-ਸਾਈਡ ਸਿਗਨਲ ਭੇਜੇਗਾ।

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

ਪੋਸਟਬੈਕ ਇੰਟੈਗ੍ਰਿਟੀ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ

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

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

ਲੇਬਲ ਨਹੀਂ, ਵਪਾਰਕ ਅਰਥ ਮੈਪ ਕਰੋ

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

ਫੋਰਵਰਡਿੰਗ ਨਿਯਮ ਵਪਾਰਕ ਅਰਥ ਅਨੁਸਾਰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ: ਯੋਗ ਲੀਡ, ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਵਿਕਰੀ, ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਸ਼ੁਰੂਆਤ, rebill, refund ਜਾਂ chargeback। ਇਸ ਨਾਲ ਰਿਪੋਰਟਿੰਗ ਸਾਫ਼ ਹੁੰਦੀ ਹੈ ਅਤੇ ਨਵੇਂ ਨੈੱਟਵਰਕ ਜੋੜਨ ‘ਤੇ ਇਵੈਂਟ ਨਾਂ ਤਰਦੇ ਨਹੀਂ।

ਫੋਰਵਰਡਿੰਗ ਗੁਣਵੱਤਾ ਦੀ ਨਿਗਰਾਨੀ ਕਰੋ

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

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

ਕਦਮ ੫: ਜੇ ਸਵੈ-ਹੋਸਟ ਨਿਯੰਤਰਣ ਚਾਹੀਦਾ ਹੋਵੇ ਤਾਂ Keitaro ਸੈਟ ਕਰੋ

ਨਤੀਜਾ: Keitaro ਕਨਵਰਜ਼ਨ ਕਾਲਬੈਕ ਪ੍ਰਾਪਤ ਕਰੇਗਾ ਅਤੇ ਟੀਮ ਦੁਆਰਾ ਹੋਸਟਿੰਗ, ਲੌਗ ਅਤੇ ਰਿਕਵਰੀ ਸੰਭਾਲਣ ਸਮੇਂ ਸਾਫ਼ ਇਵੈਂਟ ਰੂਟ ਕਰੇਗਾ।

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

ਸਕੇਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਟੈਂਪਲੇਟ ਮਿਆਰੀ ਬਣਾਓ

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

ਇੱਕ ਮਿਆਰੀ ਮੁਹਿੰਮ ਟੈਂਪਲੇਟ ਆਨਬੋਰਡਿੰਗ ਗਲਤੀਆਂ ਘਟਾਉਂਦੀ ਹੈ। ਇਹ ਲੌਗ ਰਿਵਿਊ ਵੀ ਤੇਜ਼ ਕਰਦੀ ਹੈ ਜਦੋਂ ਨੈੱਟਵਰਕ ਕਲਿੱਕ ਪਥ ਦਾ ਸਬੂਤ ਮੰਗੇ ਜਾਂ ਪਲੇਟਫਾਰਮ ਕਿਸੇ ਰਿਜੈਕਟ ਕੀਤੇ API ਇਵੈਂਟ ਦੀ ਰਿਪੋਰਟ ਕਰੇ।

ਪੋਸਟਬੈਕ ਨਿਯਮ ਕੇਂਦਰੀ ਬਣਾਓ

ਇਵੈਂਟ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਫੀਲਡਾਂ ਨੂੰ ਨਾਰਮਲਾਈਜ਼ ਕਰੋ। ਇਨਜੈਸਟ ਵੇਲੇ UTC ਵਿੱਚ ਟਾਈਮਸਟੈਂਪ ਸਟੋਰ ਕਰੋ ਅਤੇ ਸਿਰਫ ਰਿਪੋਰਟਿੰਗ ਵਿੱਚ ਹੀ ਸਮਾਂ ਖੇਤਰ ਬਦਲੋ। ਲੈਣ-ਦੇਣ ਡੀਡੁਪਲੀਕੇਸ਼ਨ ਅਤੇ ਸਥਿਤੀ ਬਦਲਾਅ ਲਈ ਇੱਕ ਕੇਂਦਰੀ ਨਿਯਮ ਵਰਤੋ।

ਬਿਨਾ ਦਸਤਾਵੇਜ਼ੀਕ੍ਰਿਤ ਛੋਟ ਦੇ ਕੈਂਪੇਨ-ਖ਼ਾਸ ਡੀਡੁਪਲੀਕੇਸ਼ਨ ਤੋਂ ਬਚੋ। ਇੱਕ-ਵਾਰ ਵਾਲੀਆਂ ਨੀਤੀਆਂ ਦੀ ਆਡਿਟ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ ਅਤੇ ਇਹ ਮਹੀਨਿਆਂ ਬਾਅਦ ਅਣਜਾਣ ਆਮਦਨੀ ਫਰਕਾਂ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੀਆਂ ਹਨ।

ਓਪਰੇਸ਼ਨਲ ਅਲਰਟ ਜੋੜੋ

ਸਵੈ-ਹੋਸਟ ਫੋਰਵਰਡਿੰਗ ਲਈ API ਫੇਲ੍ਹ, ਕਤਾਰ ਪਿੱਛੇ ਰਹਿਣਾ, ਸਰਵਰ ਗਲਤੀਆਂ, ਡਿਸਕ ਪ੍ਰੈਸ਼ਰ ਅਤੇ ਅਸਧਾਰਨ ਟ੍ਰੈਫਿਕ ਸਪੀਕ ਨੂੰ ਨਿਗਰਾਨੀ ਕਰੋ। ਓਪਰੇਟਿੰਗ ਅਨੁਮਾਨ ਵਜੋਂ, 30 ਮਿੰਟ ਤੋਂ ਵੱਧ ੨-੩% ਤੋਂ ਉੱਪਰ ਲਗਾਤਾਰ ਫੋਰਵਰਡਿੰਗ ਫੇਲ੍ਹੀਆਂ ਦੀ ਜਾਂਚ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਕਿਉਂਕਿ ਬਿਡਿੰਗ ਸਿਸਟਮ ਅਧੂਰੀ ਕਨਵਰਜ਼ਨ ਡਾਟਾ ਤੋਂ ਓਪਟੀਮਾਈਜ਼ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹਨ।

ਰਿਸਟੋਰ ਪ੍ਰਕਿਰਿਆਵਾਂ ਵੀ ਟੈਸਟ ਕਰੋ। ਜਿਹੜਾ ਬੈਕਅੱਪ ਕਦੇ ਰਿਸਟੋਰ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਉਹ ਸਿਰਫ਼ ਇੱਕ ਅਨੁਮਾਨ ਹੈ, ਰਿਕਵਰੀ ਯੋਜਨਾ ਨਹੀਂ।

ਕਦਮ ੬: ਓਪਰੇਟਿੰਗ ਹਕੀਕਤ ਅਨੁਸਾਰ ਟ੍ਰੈਕਰ ਚੁਣੋ

ਨਤੀਜਾ: ਤੁਸੀਂ ਉਹ ਚੁਣੋਗੇ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਲਾਈਵ ਸਪੈਂਡ ਦੌਰਾਨ ਕਨਫਿਗਰ, ਡੀਬੱਗ ਅਤੇ ਮਰੰਮਤ ਕਰ ਸਕੇ।

ਸਹੀ ਟ੍ਰੈਕਰ ਉਹ ਹੈ ਜਿਸਨੂੰ ਤੁਹਾਡੀ ਟੀਮ ਸਕੇਲ ਦੌਰਾਨ ਡੀਬੱਗ ਕਰ ਸਕੇ। ਫੀਚਰ ਸੂਚੀਆਂ ਦਾ ਮਹੱਤਵ ਘੱਟ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਰੂਪਾਂਤਰਨ ਰੁਕਣ, ਪੇਆਊਟ ਬਦਲਣ ਜਾਂ ਕੋਈ API ਇਵੈਂਟ ਰਿਜੈਕਟ ਕਰਨ ‘ਤੇ ਤੁਰੰਤ ਪਤਾ ਹੋਵੇ ਕਿੱਥੇ ਦੇਖਣਾ ਹੈ।

ਕਦਮ ੭: ਸਕੇਲਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਹਫ਼ਤਾਵਾਰੀ ਮਿਲਾਨ ਕਰੋ

ਨਤੀਜਾ: ਤੁਸੀਂ ਅੰਕੜਿਆਂ ‘ਤੇ ਇੰਨਾ ਭਰੋਸਾ ਕਰ ਸਕੋਗੇ ਕਿ ਅਨੁਮਾਨ ਤੋਂ ਬਿਨਾਂ ਸਪੈਂਡ ਵਧਾ ਸਕੋ।

ਇੱਕ ਨਿਯਤ ਰਿਕਨਸਿਲੀਏਸ਼ਨ ਲਯ ਨਿਰਧਾਰਤ ਕਰੋ। ਐਡ ਪਲੇਟਫਾਰਮ ਕਲਿੱਕ, ਟ੍ਰੈਕਰ ਕਲਿੱਕ, ਨੈੱਟਵਰਕ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਕਨਵਰਜ਼ਨ, ਟ੍ਰੈਕਰ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਕਨਵਰਜ਼ਨ, ਰਾਜਸਵ ਕੁੱਲ, ਫੋਰਵਰਡ ਇਵੈਂਟ ਅਤੇ ਪਲੇਟਫਾਰਮ ਦੁਆਰਾ ਸਵੀਕ੍ਰਿਤ ਇਵੈਂਟਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ।

ਸਾਪਤਾਹਿਕ ਰਿਕਨਸਿਲੀਏਸ਼ਨ ਚੈੱਕਲਿਸਟ

• ਬਾਹਰੀ ਕਲਿੱਕ ਦੀ ਤੁਲਨਾ ਟ੍ਰੈਕਰ ਰਿਕਾਰਡ ਕੀਤੇ ਕਲਿੱਕਾਂ ਨਾਲ
• ਨੈੱਟਵਰਕ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਕਨਵਰਜ਼ਨਾਂ ਦੀ ਤੁਲਨਾ ਟ੍ਰੈਕਰ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਕਨਵਰਜ਼ਨਾਂ ਨਾਲ
• ਨੈੱਟਵਰਕ ਪੇਆਊਟ ਕੁੱਲ ਦੀ ਤੁਲਨਾ ਟ੍ਰੈਕਰ ਰੈਵੈਨਿਊ ਕੁੱਲ ਨਾਲ
• ਟ੍ਰੈਕਰ ਫੋਰਵਰਡ ਇਵੈਂਟ ਦੀ ਤੁਲਨਾ ਪਲੇਟਫਾਰਮ ਸਵੀਕ੍ਰਿਤ ਇਵੈਂਟਾਂ ਨਾਲ
• ਰਿਫੰਡ, ਚਾਰਜਬੈਕ ਅਤੇ ਅਸਵੀਕਾਰਿਤ ਸਥਿਤੀਆਂ ਆਫ਼ਰ ਅਨੁਸਾਰ
• ਸਰੋਤ, ਟ੍ਰੈਕਰ, ਨੈੱਟਵਰਕ ਅਤੇ ਰਿਪੋਰਟ ਐਕਸਪੋਰਟ ਵਿੱਚ ਟਾਈਮ-ਜ਼ੋਨ ਸੈਟਿੰਗ

ਟ੍ਰੈਫਿਕ ਸਰੋਤ ਅਤੇ ਆਫ਼ਰ ਮਾਡਲ ਅਨੁਸਾਰ ਸਧਾਰਣ ਵੈਰੀਐਂਸ ਦਸਤਾਵੇਜ਼ ਕਰੋ। ਬੇਸਲਾਈਨ ਬਿਨਾਂ ਹਰ ਫਰਕ ਤੁਰੰਤ ਸੰਕਟ ਲੱਗਦਾ ਹੈ ਅਤੇ ਟੀਮ ਆਮ attribution ਸ਼ੋਰ ਪਿੱਛੇ ਸਮਾਂ ਬਰਬਾਦ ਕਰਦੀ ਹੈ।

ਸਿਰਫ਼ ਟ੍ਰੈਕਰ ਨਹੀਂ, ਲਾਈਵ ਸੇਲਜ਼ ਫਲੋ ਦੀ ਵੀ ਪੁਸ਼ਟੀ ਕਰੋ

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

ਪਬਲਿਕ ਰਿਸਰਚ ਟੂਲ ਸੋਚ-ਵਿਚਾਰ ਕੇ ਵਰਤੋ। Meta Ad Library ਦਿਖਾ ਸਕਦੀ ਹੈ ਕਿ ਮਿਲਦੇ-ਜੁਲਦੇ ਵਿਗਿਆਪਨ ਸਰਗਰਮ ਹਨ ਕਿ ਨਹੀਂ, ਪਰ ਇਹ ਲਾਭਕਾਰੀਪਨ, ਭਾਗੀਦਾਰੀ ਸਥਿਤੀ ਜਾਂ ਪੇਆਊਟ ਦੀ ਗੁਣਵੱਤਾ ਨਹੀਂ ਸਾਬਤ ਕਰਦੀ। ਕ੍ਰੀਏਟਿਵ ਰਿਸਰਚ ਨੂੰ ਅਸਲ ਨੈੱਟਵਰਕ ਡਾਟਾ ਅਤੇ ਟ੍ਰੈਕਰ ਰਿਕਨਸਿਲੀਏਸ਼ਨ ਨਾਲ ਜੋੜ ਕੇ ਵੇਖੋ।

ਕਦਮ ੮: ਕੇਵਲ ਤਦ ਹੀ ਸਕੇਲ ਕਰੋ ਜਦ ਟ੍ਰੈਕਿੰਗ ਅਤੇ ਆਫ਼ਰ ਗੁਣਵੱਤਾ ਇੱਕਸਾਰ ਹੋਣ

ਨਤੀਜਾ: ਤੁਹਾਡੇ CAPI ਇਵੈਂਟ ਅਸਲੀ ਵਪਾਰਕ ਨਤੀਜੇ ਦਰਸਾਉਣ, ਨਾ ਕਿ ਕੇਵਲ ਤਕਨੀਕੀ ਤੌਰ ‘ਤੇ ਵੈਧ ਕਾਲਬੈਕ।

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

ਇਥੇ ਹੀ Daily Intel Service ਇਸ ਵਰਕਫਲੋ ਵਿੱਚ ਫਿੱਟ ਹੁੰਦਾ ਹੈ: ਇਹ ਓਪਰੇਟਰਾਂ ਨੂੰ ਸਰਗਰਮ ਸੇਲਜ਼ ਫਲੋ, ਮੌਜੂਦਾ ਕ੍ਰੀਏਟਿਵ ਪਥ ਅਤੇ ਲਾਈਵ ਆਫ਼ਰ ਸਿਗਨਲ ਦੀ ਤੁਲਨਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਉਹ ਸਿਰਫ਼ ਬੁੱਢੀ ਹੋਈ ਸੰਭਾਵਨਾ ਦੀ attribution ਸੁਧਾਰਨ ਵਿੱਚ ਸਮਾਂ ਨਾਹ ਬਰਬਾਦ ਕਰਨ। ਜਿਹਨਾਂ ਟੀਮਾਂ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਟ੍ਰੈਕਿੰਗ ਮੌਜੂਦ ਹੈ, ਉਨ੍ਹਾਂ ਲਈ Daily Intel Service ਮੈਥਡੋਲੋਜੀ ਦੱਸਦੀ ਹੈ ਕਿ ਸਬੂਤ-ਆਧਾਰਿਤ ਆਫ਼ਰ ਅਤੇ ਫਨਲ ਸਮੀਖਿਆ ਨੂੰ ਹੋਹੱਲੇ ਤੋਂ ਕਿਵੇਂ ਵੱਖ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ।

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

ਆਮ ਗਲਤੀਆਂ ਜੋ S2S ਐਟ੍ਰਿਬਿਊਸ਼ਨ ਖਰਾਬ ਕਰਦੀਆਂ ਹਨ

• ਆਫ਼ਰ URL ਵਿੱਚ ਪਲੇਟਫਾਰਮ ਕਲਿੱਕ ਆਈਡੀ ਤਾਂ ਭੇਜੀ ਪਰ ਟ੍ਰੈਕਰ ਕਲਿੱਕ ਆਈਡੀ ਨਹੀਂ
• ਲੈਣ-ਦੇਣ ਆਈਡੀ ਤੋਂ ਬਿਨਾਂ ਪੋਸਟਬੈਕ ਸਵੀਕਾਰ ਕਰਨਾ
• pending, approved, refunded ਅਤੇ rejected ਇਵੈਂਟਾਂ ਨੂੰ ਇੱਕੋ ਨਤੀਜੇ ਵਜੋਂ ਮੰਨਣਾ
• ਇੱਕ ਪੇਆਊਟ ਕਾਲਬੈਕ ਤੋਂ ਕਈ ਪਲੇਟਫਾਰਮ ਇਵੈਂਟ ਭੇਜਣਾ ਬਿਨਾਂ ਰੂਟਿੰਗ ਨਿਯਮਾਂ ਦੇ
• ਵਿਚਕਾਰ URL ਟੈਂਪਲੇਟ ਬਦਲਣਾ ਅਤੇ ਵਰਜਨ ਨੋਟ ਨਾ ਰੱਖਣਾ
• ਇਕੋ ਓਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਇਵੈਂਟ ਵਿੱਚ ਅਨੁਮਾਨਿਤ LTV ਅਤੇ ਅਸਲੀ ਪੇਆਊਟ ਮਿਲਾਉਣਾ
• CAPI ਫੋਰਵਰਡਿੰਗ ਚਾਲੂ ਕਰਨ ਤੋਂ ਬਾਅਦ API ਰਿਜੈਕਟ ਲੌਗ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ
• ਵੱਖ-ਵੱਖ ਟਾਈਮ ਜ਼ੋਨ ਜਾਂ ਐਟ੍ਰਿਬਿਊਸ਼ਨ ਵਿੰਡੋ ਨਾਲ ਰਿਪੋਰਟਾਂ ਦੀ ਤੁਲਨਾ ਕਰਨਾ

ਸਥਿਰ ਸਰਵਰ-ਸਾਈਡ ਟ੍ਰੈਕਿੰਗ ਆਮ ਤੌਰ ‘ਤੇ ਪ੍ਰਕਿਰਿਆ ਅਨੁਸ਼ਾਸਨ ਨਾਲ ਬਣਦੀ ਹੈ: ਘੱਟ ਇਵੈਂਟ ਨਾਂ, ਸਖ਼ਤ ਫੀਲਡ ਵੈਰੀਫਿਕੇਸ਼ਨ, ਸਪਸ਼ਟ ਸਥਿਤੀ ਨਿਯਮ ਅਤੇ ਸਪੈਂਡ ਵਧਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਰਿਕਨਸਿਲੀਏਸ਼ਨ।

ਵਾਰ-ਵਾਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ

Q: Voluum ਵਿੱਚ ਅਫ਼ਿਲੀਏਟ ਮੁਹਿੰਮਾਂ ਲਈ ਸਰਵਰ-ਸਾਈਡ ਟ੍ਰੈਕਿੰਗ ਕੀ ਹੈ?
A: Voluum ਵਿੱਚ ਅਫ਼ਿਲੀਏਟ ਸਰਵਰ-ਸਾਈਡ ਟ੍ਰੈਕਿੰਗ ਇੱਕ ਵਰਕਫਲੋ ਹੈ ਜਿੱਥੇ ਅਫ਼ਿਲੀਏਟ ਨੈੱਟਵਰਕ Voluum ਨੂੰ conversion postback ਭੇਜਦਾ ਹੈ ਅਤੇ Voluum ਉਸਨੂੰ ਰਿਕਾਰਡ, ਡੀਡੁਪਲੀਕੇਟ ਕਰਕੇ ਸਿਰਵਰ-ਸਾਈਡ API ਰਾਹੀਂ ਐਡ ਪਲੇਟਫਾਰਮਾਂ ਨੂੰ ਭੇਜ ਸਕਦਾ ਹੈ।

Q: Postback URL ਅਤੇ CAPI ਫੋਰਵਰਡਿੰਗ ਵਿੱਚ ਕੀ ਅੰਤਰ ਹੈ?
A: Postback URL ਅਫ਼ਿਲੀਏਟ ਨੈੱਟਵਰਕ ਤੋਂ ਟ੍ਰੈਕਰ ਨੂੰ conversion ਡਾਟਾ ਭੇਜਦੀ ਹੈ, ਜਦਕਿ CAPI ਫੋਰਵਰਡਿੰਗ ਟ੍ਰੈਕਰ ਤੋਂ ਮੈਪ ਕੀਤੇ ਇਵੈਂਟ ਟ੍ਰੈਕਰ ਦੇ ਪਲੇਟਫਾਰਮ API ਵੱਲ ਭੇਜਦੀ ਹੈ।

Q: CAPI ਲਈ RedTrack, Keitaro ਨਾਲੋਂ ਵਧੀਆ ਹੈ?
A: ਆਮ ਤੌਰ ‘ਤੇ ਇਵੈਂਟ ਫੋਰਵਰਡਿੰਗ ਨੂੰ ਮੈਨੇਜ ਕਰਨਾ RedTrack ਨਾਲ ਸੌਖਾ ਹੁੰਦਾ ਹੈ, ਜਦਕਿ Keitaro ਵਧੇਰੇ ਸਵੈ-ਹੋਸਟ ਨਿਯੰਤਰਣ ਦਿੰਦਾ ਹੈ। ਵਧੀਆ ਚੋਣ ਇਸ ਗੱਲ ‘ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ ਤੁਹਾਡੀ ਟੀਮ ਮੈਨੇਜਡ ਸੈਟਅਪ ਗਤੀ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੀ ਹੈ ਜਾਂ ਇੰਫਰਾਸਟ੍ਰਕਚਰ ਨਿਯੰਤਰਣ ਨੂੰ।

Q: ਇੱਕ ਅਫ਼ਿਲੀਏਟ ਪੋਸਟਬੈਕ ਵਿੱਚ ਕਿਹੜੇ ਫੀਲਡ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ?
A: ਇੱਕ ਭਰੋਸੇਯੋਗ ਅਫ਼ਿਲੀਏਟ ਪੋਸਟਬੈਕ ਵਿੱਚ ਟ੍ਰੈਕਰ ਕਲਿੱਕ ਆਈਡੀ, ਲੈਣ-ਦੇਣ ਆਈਡੀ, ਪੇਆਊਟ, ਕਰੰਸੀ, ਕਨਵਰਜ਼ਨ ਸਥਿਤੀ ਅਤੇ ਇਵੈਂਟ ਟਾਈਮਸਟੈਂਪ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾਲ ਹੀ ਡੀਡੁਪਲੀਕੇਸ਼ਨ ਅਤੇ ਸਥਿਤੀ-ਬਦਲਾਅ ਨੀਤੀਆਂ।

Q: ਮੈਂ ਸਰਵਰ-ਸਾਈਡ ਟ੍ਰੈਕਿੰਗ ਡੇਟਾ ਕਿੰਨੀ ਵਾਰ ਰਿਕਨਸਾਈਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?
A: ਬੇਸਲਾਈਨ ਵਜੋਂ ਹਫ਼ਤਾਵਾਰੀ ਰਿਕਨਸਾਈਲ ਕਰੋ ਅਤੇ ਨਵੀਆਂ ਲਾਂਚਾਂ ਦੌਰਾਨ ਘੰਟਾਵਾਰ ਜਾਂ ਰੋਜ਼ਾਨਾ ਜਾਂਚ ਕਰੋ। ਸਰੋਤ ਕਲਿੱਕ, ਟ੍ਰੈਕਰ ਕਲਿੱਕ, ਨੈੱਟਵਰਕ ਕਨਵਰਜ਼ਨ, ਟ੍ਰੈਕਰ ਰੈਵੈਨਿਊ, ਫੋਰਵਰਡ ਇਵੈਂਟ ਅਤੇ ਪਲੇਟਫਾਰਮ ਸਵੀਕ੍ਰਿਤ ਇਵੈਂਟਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ।

Q: ਕੀ ਇਹ ਕਾਨੂੰਨੀ, ਟੈਕਸ ਜਾਂ ਵਿੱਤੀ ਸਲਾਹ ਹੈ?
A: ਨਹੀਂ। ਇਹ ਵਰਤੋਂ ਸਿੱਖਿਆ ਅਤੇ ਮਾਰਕੀਟ-ਇੰਟੈਲੀਜੈਂਸ ਸੰਦਰਭ ਹੈ। ਗੋਪਨੀਯਤਾ, ਵਿਗਿਆਪਨ, ਟੈਕਸ ਅਤੇ ਠੇਕਾ-ਸੰਬੰਧੀ ਲੋੜਾਂ ਖੇਤਰ ਅਨੁਸਾਰ ਬਦਲਦੀਆਂ ਹਨ ਅਤੇ ਯੋਗ ਪੇਸ਼ੇਵਰਾਂ ਨਾਲ ਸਮੀਖਿਆ ਕੀਤੀਆਂ ਜਾਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ.