ਐਫਿਲੀਏਟ ਫਨਲ ਲਈ ਸਰਵਰ-ਸਾਈਡ GTM ਟਿਊਟੋਰਿਯਲ

ਕਦਮ 1: GTM ਖੋਲ੍ਹਣ ਤੋਂ ਪਹਿਲਾਂ ਇਵੈਂਟ ਠੇਕਾ ਨਿਰਧਾਰਤ ਕਰੋ

ਸਰਵਰ-ਸਾਈਡ ਸੈਟਅੱਪ ਉਤਨਾ ਹੀ ਭਰੋਸੇਯੋਗ ਹੁੰਦਾ ਹੈ ਜਿੰਨਾ ਇਸਦੇ ਪਿੱਛੇ ਦਾ ਇਵੈਂਟ ਠੇਕਾ। ਇੱਕ ਛੋਟੀ ਸਕੀਮਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜਿਸ ਨੂੰ ਹਰ ਪੰਨਾ, webhook ਅਤੇ ਪਲੇਟਫਾਰਮ ਗੰਤੀ-ਸਥਾਨ ਫਾਲੋ ਕਰ ਸਕਣ।

ਅਧਿਕਤਰ ਐਫਿਲੀਏਟ ਫਨਲਾਂ ਲਈ ਪਹਿਲਾ ਇਵੈਂਟ ਸੈੱਟ 3 ਤੋਂ 5 ਬਿਜ਼ਨਸ ਇਵੈਂਟਾਂ ਦਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:

• view_content ਵਿਕਰੀ ਪੰਨੇ ਜਾਂ VSL ਵੇਖਣ ਲਈ
• lead ਓਪਟ-ਇਨ ਜਾਂ ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਲਈ
• checkout_start ਭੁਗਤਾਨ ਮਨਸ਼ਾ ਲਈ
• purchase ਪੁਸ਼ਟੀਸ਼ੁਦਾ ਰੂਪਾਂਤਰਨ ਲਈ
• refund ਸਿਰਫ ਜੇ ਆਫਰ ਬੈਕਐਂਡ ਇਸਨੂੰ ਲਗਾਤਾਰ ਭੇਜ ਸਕੇ

ਹਰ ਇਵੈਂਟ ਵਿੱਚ event_id, event_name, event_time, offer_id, campaign_id, source, medium, ਅਤੇ consent_state ਹੋਣਾ ਲਾਜ਼ਮੀ ਹੈ। ਇੱਕ ਹੀ ਯੂਜ਼ਰ ਕਿਰਿਆ ਲਈ ਇੱਕ ਅਬਦਿਲ event_id ਵਰਤੋ, ਮੁੜ-ਪ੍ਰਯਾਸਾਂ ਸਮੇਤ, ਤਾਂ ਜੋ ਬਰਾਊਜ਼ਰ ਅਤੇ ਸਰਵਰ ਇਵੈਂਟ ਡੁਪਲੀਕੇਟ ਵਜੋਂ ਗਿਣੇ ਜਾਣ ਦੀ ਬਜਾਏ ਡਿਪਲੀਕੇਟ ਹਟਾਏ ਜਾ ਸਕਣ।

ਵਿਹਾਰਕ ਸਵੀਕਾਰਤਾ ਗੇਟ

ਡਿਪਲੌਇਮੈਂਟ ਤੋਂ ਪਹਿਲਾਂ ਸਵੀਕਾਰਤਾ ਗੇਟ ਲਗਾਓ। ਪਹਿਲੀ ਪ੍ਰੋਡਕਸ਼ਨ ਪਾਸ ਲਈ ਵਾਜਬ ਅੰਦਾਜ਼ੀ ਲਕਸ਼ ਹਨ: ਸਕੀਮਾ ਪਾਸ ਰੇਟ 98% ਜਾਂ ਵੱਧ, ਡਿਪਲੀਕੇਟ ਟਕਰਾਅ 2% ਜਾਂ ਘੱਟ, ਅਤੇ ਇਵੈਂਟ-ਸਮੇਂ ਦੀ ਝੁਕਾਅ 120 ਸਕਿੰਟ ਤੋਂ ਘੱਟ। ਇਨ੍ਹਾਂ ਨੂੰ ਸਰਵਭੌਮ ਮਾਪਦੰਡ ਨਹੀਂ, ਸਗੋਂ ਓਪਰੇਸ਼ਨਲ ਅੰਦਾਜ਼ੇ ਮੰਨੋ।

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

ਸਰੋਤ ਮੁੱਲ ਸਥਿਰ ਰੱਖੋ

ਕੈਂਪੇਨ ਫੀਲਡ SGTM, ਐਡ ਪਲੇਟਫਾਰਮਾਂ ਅਤੇ ਤੁਹਾਡੇ ਰਿਪੋਰਟਿੰਗ ਲੇਅਰ ਵਿਚਕਾਰ ਇੱਕੋ ਤਰ੍ਹਾਂ ਡਿਕੋਡ ਹੋਣ ਚਾਹੀਦੇ ਹਨ। utm_source, utm_medium, utm_campaign ਅਤੇ ਰਚਨਾਤਮਕ ਪਛਾਣਕਾਰ (creative identifiers) ਦਾ ਰੂਪ ਇੱਕੋ ਰਹੇ ਇਸ ਲਈ ਇਵੈਂਟ ਰਾਊਟਿੰਗ ਤੋਂ ਪਹਿਲਾਂ UTM ਮੁੱਲਾਂ ਨੂੰ ਨਾਰਮਲਾਈਜ਼ ਕਰੋ।

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

ਕਦਮ 2: ਸਰਵਰ ਕਨਟੇਨਰ ਅਤੇ ਐਂਡਪੌਇੰਟ ਪ੍ਰਦਾਨ ਕਰੋ

ਹੇਠਲੇ API ਨਾਲ ਜੁੜਨ ਤੋਂ ਪਹਿਲਾਂ Google Tag Manager ਸਰਵਰ ਕਨਟੇਨਰ ਬਣਾਓ। ਇਸ ਨਾਲ ਡਿਪਲੌਇਮੈਂਟ ਕ੍ਰਮ ਸਪੱਸ਼ਟ ਰਹਿੰਦਾ ਹੈ: ਪਹਿਲਾਂ ਇਵੈਂਟ ਲਓ, ਫਿਰ ਉਹਨਾਂ ਦੀ ਜਾਂਚ ਕਰੋ, ਫਿਰ ਕੇਵਲ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਪੇਲੋਡ ਫੋਰਵਰਡ ਕਰੋ।

ਇੱਕ ਬੇਸਲਾਈਨ ਪ੍ਰਾਵਧਾਨ ਮਾਰਗ ਇਹੋ ਜਿਹਾ ਹੁੰਦਾ ਹੈ:

1. ਪ੍ਰੋਡਕਸ਼ਨ ਲਈ ਨਵਾਂ GTM ਸਰਵਰ ਕਨਟੇਨਰ ਬਣਾਓ।
2. ਇਸਨੂੰ ਸਮਰਥਨ ਪ੍ਰਾਪਤ ਕਲਾਊਡ ਵਾਤਾਵਰਣ ਵਿੱਚ ਡਿਪਲੌਇ ਕਰੋ।
3. ਪਹਿਲੇ-ਪੱਖ ਦਾ ਸਬਡੋਮੇਨ ਜੋੜੋ ਜਿਵੇਂ track.example.com।
4. HTTPS ਨੂੰ ਲਾਜ਼ਮੀ ਬਣਾਓ।
5. ਵੱਖਰੇ dev, staging, ਅਤੇ prod ਵਾਤਾਵਰਣ ਬਣਾਓ।

ਐਫਿਲੀਏਟ ਟ੍ਰੈਫਿਕ ਲਈ ਹੋਸਟਿੰਗ ਚੋਣ

ਹੋਸਟਿੰਗ ਕੇਵਲ ਸਟਿਕਰ ਕੀਮਤ ਦੇ ਆਧਾਰ ਤੇ ਨਹੀਂ, ਸਗੋਂ ਬਰਸਟ ਵਰਤਾਓ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਹੁਨਰ ਦੇ ਆਧਾਰ ਤੇ ਚੁਣੋ।

ਇਹ ਸਿਰਫ਼ ਯੋਜਨਾ ਅੰਦਾਜ਼ੇ ਹਨ। ਅਸਲ ਲਾਗਤ ਖੇਤਰ, ਬੇਨਤੀ ਵਾਲੀਮ, ਲਾਗ ਰਿਟੈਨਸ਼ਨ, ਐਨਰਿਚਮੈਂਟ ਲਾਜ਼ਿਕ ਅਤੇ ਰਿਟ੍ਰਾਈ ਵਰਤਾਓ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ।

ਡੋਮੇਨ ਅਤੇ TLS ਬੇਸਲਾਈਨ

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

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

ਕਦਮ 3: ਫਨਲ ਵਿਹਾਰ ਬਿਨਾਂ ਬਦਲੇ ਬਰਾਊਜ਼ਰ ਇਵੈਂਟ SGTM ਨੂੰ ਭੇਜੋ

ਪਹਿਲਾ ਬਰਾਊਜ਼ਰ-ਤੋਂ-ਸਰਵਰ ਪੁਲ ਮੌਜੂਦਾ ਪੰਨੇ ਦੇ ਵਿਹਾਰ ਨੂੰ ਬਣਾਇਆ ਨਹੀਂ ਬਦਲਣਾ ਚਾਹੀਦਾ। ਇੱਕੋ ਵਾਰ ਸਾਰੇ ਟੈਗ ਮੁੜ ਨਾ ਬਣਾਓ; ਮੌਜੂਦਾ dataLayer ਇਵੈਂਟਾਂ ਨੂੰ SGTM ਵੱਲ ਭੇਜੋ ਅਤੇ ਐਨਰਿਚਮੈਂਟ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਆਉਟਪੁੱਟ ਦੀ ਤੁਲਨਾ ਕਰੋ।

ਵੈਬ ਕਨਟੇਨਰ ਵਿੱਚ ਇਵੈਂਟ ਨਾਮ ਸਥਿਰ ਰੱਖੋ, ਸਰਵਰ ਐਂਡਪੌਇੰਟ ਨੂੰ ਇਵੈਂਟ ਗੰਤੀ-ਸਥਾਨ ਵਜੋਂ ਜੋੜੋ, ਅਤੇ ਇੱਕੋ ਕਿਰਿਆ ਦੇ ਬਰਾਊਜ਼ਰ ਤੇ ਸਰਵਰ ਕਾਪੀ ਲਈ ਇੱਕੋ event_id ਭੇਜੋ। ਰਿਟ੍ਰਾਈਆਂ 1 ਜਾਂ 2 ਕੋਸ਼ਿਸ਼ਾਂ ਤੱਕ ਸੀਮਿਤ ਰੱਖੋ। ਬਹੁਤ ਜ਼ਿਆਦਾ ਰਿਟ੍ਰਾਈ ਇਕ ਛੋਟੀ timeout ਸਮੱਸਿਆ ਨੂੰ ਡੁਪਲੀਕੇਟ-ਇਵੈਂਟ ਮੁੱਦਾ ਬਣਾ ਸਕਦੀ ਹੈ।

ਨਿਊਨਤਮ ਲਾਂਚ ਪੈਟਰਨ

ਸੁਰੱਖਿਅਤ ਪਹਿਲੇ ਪੈਟਰਨ ਵਿੱਚ ਤਿੰਨ ਗੱਲਾਂ ਹੁੰਦੀਆਂ ਹਨ:

• ਮੌਜੂਦਾ ਫਨਲ ਇਵੈਂਟ SGTM ਨੂੰ ਫੋਰਵਰਡ ਕਰਦਾ ਹੈ।
• ਮੌਜੂਦਾ ਇਵੈਂਟ ਨਾਮ ਅਤੇ ਰੂਪਾਂਤਰਨ ਪਰਿਭਾਸ਼ਾਵਾਂ ਬਣੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ।
• ਅਸਵੀਕਾਰ ਕੀਤੇ ਇਵੈਂਟ ਲਾਗ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਜਿਸ ਨਾਲ ਸਕੀਮਾ ਫੇਲ੍ਹ ਹੋਣ ਦੀ ਡੀਬੱਗਿੰਗ ਲਈ ਕਾਫ਼ੀ ਵੇਰਵਾ ਮਿਲਦਾ ਹੈ।

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

ਕਦਮ 4: ਇਵੈਂਟ ਨਾਰਮਲਾਈਜ਼, ਸੈਨਿਟਾਈਜ਼ ਅਤੇ ਰਾਊਟ ਕਰੋ

SGTM ਦੇ ਅੰਦਰ ਇੱਕ ਐਸਾ ਵੈਲਿਡੇਸ਼ਨ ਫਲੋ ਬਣਾਓ ਜੋ ਅਧੂਰੇ ਇਵੈਂਟ ਰੱਦ ਕਰੇ, ਸਵੀਕਾਰ ਕੀਤੇ ਫੀਲਡ ਨਾਰਮਲ ਕਰੇ, ਮਨ੍ਹਾਂ ਡਾਟਾ ਹਟਾਏ ਅਤੇ ਸਿਰਫ਼ ਪਲੇਟਫਾਰਮ-ਰੇਡੀ ਪੇਲੋਡ ਹੀ ਫੋਰਵਰਡ ਕਰੇ।

ਘੱਟੋ-ਘੱਟ ਸਰਵਰ ਕਨਟੇਨਰ ਨੂੰ ਇਹ ਜਾਂਚ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ:

• ਜ਼ਰੂਰੀ ਪਛਾਣਕਾਰ: event_id, event_time, offer_id, ਅਤੇ campaign_id
• ਇਵੈਂਟ ਨਾਮਕਰਨ: ਕੇਵਲ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਨਾਮ
• ਸਹਿਮਤੀ ਹਾਲਤ: ਮੌਜੂਦ ਅਤੇ ਸਮਝ ਆਉਣਯੋਗ
• ਟਾਈਮਸਟੈਂਪ ਫਾਰਮੈਟ: UTC ਜਾਂ ਇਕ ਸਹਿਮਤ ਮਿਆਰ
• ਸੰਵੇਦਨਸ਼ੀਲ ਫੀਲਡ: ਤਦ ਹੀ ਭੇਜੋ ਜੇ ਕਾਨੂੰਨੀ ਆਧਾਰ ਦਸਤਾਵੇਜ਼ਤ ਹੋਵੇ ਅਤੇ ਪਲੇਟਫਾਰਮ ਨੀਤੀ ਵਰਤਣ ਦੀ ਇਜਾਜ਼ਤ ਦੇਵੇ

ਹੈਸ਼ ਕਰਨਾ ਸਹਿਮਤੀ ਜਾਂ ਨੀਤੀ ਸਮੀਖਿਆ ਦਾ ਬਦਲ ਨਹੀਂ ਹੈ। ਜੇ ਤੁਸੀਂ CAPI ਨੂੰ ਪਛਾਣਕਾਰ ਭੇਜਦੇ ਹੋ, ਤਾਂ ਦਸਤਾਵੇਜ਼ ਕਰੋ ਕਿ ਕੀ ਭੇਜਿਆ ਜਾ ਰਿਹਾ ਹੈ, ਕਿਉਂ ਮਨਜ਼ੂਰ ਹੈ ਅਤੇ ਡਿਲੀਸ਼ਨ ਜਾਂ ਸਪਰੇਸ਼ਨ ਬੇਨਤੀਆਂ ਕਿਵੇਂ ਸੰਭਾਲੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।

CAPI ਮੈਪਿੰਗ

SGTM ਇਵੈਂਟ ਤਦ ਹੀ Meta CAPI ਨਾਲ ਮੈਪ ਕਰੋ ਜਦੋਂ ਸਟੇਜਿੰਗ ਵਿੱਚ ਸਕੀਮਾ ਪਾਸ ਹੋ ਜਾਵੇ। Facebook Conversions API setup guide ਇਹ ਦੱਸਣ ਲਈ ਮੁੱਖ ਸਰੋਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਇਵੈਂਟ ਭੇਜੇ ਜਾਂਦੇ ਹਨ, event_id ਕਿਵੇਂ ਦੁਬਾਰਾ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਬਰਾਊਜ਼ਰ/ਸਰਵਰ ਡੁਪਲੀਕੇਸ਼ਨ ਕਿਵੇਂ ਪੁਸ਼ਟੀ ਹੁੰਦੀ ਹੈ।

ਪਲੇਟਫਾਰਮ ਡਾਇਗਨੋਸਟਿਕ ਨੂੰ ਸਮਝਣ ਤੋਂ ਪਹਿਲਾਂ event match quality expectations ਜ਼ਰੂਰ ਵੇਖੋ। ਇਵੈਂਟ ਮੈਚ ਗੁਣਵੱਤਾ ਸੁਧਰ ਸਕਦੀ ਹੈ ਜਦੋਂ ਪਛਾਣਕਾਰ ਅਤੇ ਸਰੋਤ ਫੀਲਡ ਸਾਫ਼ ਹੁੰਦੇ ਹਨ, ਪਰ ਅਸਲ ਨਤੀਜਾ ਸਹਿਮਤੀ ਕਵਰੇਜ, ਟ੍ਰੈਫਿਕ ਸਰੋਤ, ਡਿਵਾਈਸ ਮਿਲਾਵਟ ਅਤੇ ਆਫਰ ਫਲੋ ’ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।

ਗੰਤੀ-ਸਥਾਨ ਮੈਟ੍ਰਿਕਸ

ਇੱਕ ਰਾਊਟਿੰਗ ਮੈਟ੍ਰਿਕਸ ਗਲਤ ਓਵਰ-ਸ਼ੇਅਰਿੰਗ ਰੋਕਦੀ ਹੈ ਅਤੇ ਬਾਅਦ ਦੀਆਂ ਆਡਿਟਾਂ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੀ ਹੈ।

ਕਦਮ 5: ਸਕੇਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨ ਲੂਪਾਂ ਵਿੱਚ ਪੁਸ਼ਟੀ ਕਰੋ

ਇੱਕ ਸਫਲ ਟੈਸਟ ਇਵੈਂਟ ਦੇ ਆਧਾਰ ’ਤੇ SGTM ਦਾ ਫੈਸਲਾ ਨਾ ਕਰੋ। ਸਕੇਲਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਲੋਕਲ, ਸਟੇਜਿੰਗ ਅਤੇ ਸੀਮਤ ਲਾਈਵ—ਇਹ ਤਿੰਨ ਲੂਪਾਂ ਵਿੱਚ ਪੁਸ਼ਟੀ ਕਰੋ।

1. ਲੋਕਲ ਲੂਪ: ਇੱਕ ਫਨਲ ਰਾਹੀਂ ਕ੍ਰਿਤ੍ਰਿਮ ਇਵੈਂਟ ਭੇਜੋ ਅਤੇ ਸਵੀਕਾਰ/ਅਸਵੀਕਾਰ ਕੇਸ ਪੱਕੇ ਕਰੋ।
2. ਸਟੇਜਿੰਗ ਲੂਪ: ਟ੍ਰੈਫਿਕ ਵਾਲਿਊਮ ਮਨਜ਼ੂਰ ਕਰੇ ਤਾਂ 24 ਘੰਟੇ ਲਈ 1,000 ਤੋਂ 5,000 ਘੱਟ-ਖਤਰੇ ਵਾਲੇ ਇਵੈਂਟ ਚਲਾਓ।
3. ਲਾਈਵ ਲੂਪ: ਸੀਮਿਤ ਪੇਡ ਟ੍ਰੈਫਿਕ ਵਰਤੋ ਅਤੇ SGTM ਲਾਗ, ਐਡ ਪਲੇਟਫਾਰਮ ਇਵੈਂਟ ਲਾਗ ਅਤੇ ਆਫਰ-ਬੈਕਐਂਡ ਰੂਪਾਂਤਰਨਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ।

QA ਸਕੋਰਕਾਰਡ

ਇਹ ਥ੍ਰੈਸ਼ਹੋਲਡ ਗਾਰੰਟੀ ਨਹੀਂ। ਇਹ ਵਿਹਾਰਕ ਗੇਟ ਹਨ ਜੋ ਟੀਮ ਨੂੰ ਜਾਂਚਣ ਲਈ ਪ੍ਰੇਰਿਤ ਕਰਦੇ ਹਨ, ਤਾਂ ਜੋ ਖਰਚਾ ਸਮੱਸਿਆ ਨੂੰ ਓਹਲੇ ਨਾ ਰੱਖੇ।

ਰਿਕਨਸਿਲੀਏਸ਼ਨ ਤਰੀਕਾ

ਹਰ 24 ਤੋਂ 48 ਘੰਟਿਆਂ ਵਿੱਚ ਤਿੰਨ ਸਰੋਤ ਤੁਲਨਾ ਕਰੋ: SGTM ਕੱਚੇ ਲਾਗ, ਪਲੇਟਫਾਰਮ ਇਵੈਂਟ ਡਾਇਗਨੋਸਟਿਕ ਅਤੇ ਆਫਰ-ਬੈਕਐਂਡ ਰੂਪਾਂਤਰਨ। ਜੇ ਬੈਕਐਂਡ 100 ਖਰੀਦਾਂ ਦਿਖਾਏ, SGTM 130 purchase ਇਵੈਂਟ ਅਤੇ ਪਲੇਟਫਾਰਮ 75 ਦਿਖਾਏ, ਤਾਂ ਸੰਭਵ ਹੈ ਕਿ ਡੁਪਲੀਕੇਟ ਹੈਂਡਲਿੰਗ ਅਤੇ ਡਿਲੀਵਰੀ ਦੋਵੇਂ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਹੋਣ।

ਡੀਬੱਗਿੰਗ ਦੌਰਾਨ ਨਵੀਆਂ ਕੈਂਪੇਨ ਤਬਦੀਲੀਆਂ ਰੋਕੋ। ਰਚਨਾਤਮਕ ਟੈਸਟ, ਬੋਲੀ (bid) ਤਬਦੀਲੀਆਂ ਅਤੇ ਰਾਊਟਿੰਗ ਤਬਦੀਲੀਆਂ ਟ੍ਰੈਕਿੰਗ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਸਮੱਸਿਆ ਵਾਂਗ ਵਿਖਾ ਸਕਦੀਆਂ ਹਨ।

ਕਦਮ 6: ਖਰਚਾ, ਕਾਨੂੰਨੀ ਅਨੁਕੂਲਤਾ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਖ਼ਤਰਾ ਕਾਬੂ ਕਰੋ

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

ਆਮ ਤੌਰ ’ਤੇ ਕਾਰਗਰ ਖਰਚਾ ਨਿਯੰਤਰਣ:

• ਰੂਪਾਂਤਰਨਾਂ ਨੂੰ ਛੋਟਾ ਅਤੇ ਭਵਿੱਖਯੋਗ ਰੱਖੋ।
• ਹਰ ਪੰਨਾ ਇੰਟਰਐਕਸ਼ਨ ਹਰ ਗੰਤੀ-ਸਥਾਨ ’ਤੇ ਨਾ ਭੇਜੋ।
• ਵਿਸਥਾਰਿਤ ਲਾਗ ਸਿਰਫ ਉਹਨਾਂ ਦਿਨਾਂ ਹੀ ਰੱਖੋ ਜਿੰਨੇ QA ਅਤੇ ਆਡਿਟ ਲਈ ਲੋੜੀਂਦੇ ਹਨ।
• ਰੋਲਆਉਟ ਦੌਰਾਨ ਹਫ਼ਤੇ ਵਿੱਚ ਇੱਕ ਵਾਰ SGTM ਅਤੇ CAPI ਖਰਚਾ ਇਕੱਠੇ ਸਮੀਖਿਆ ਕਰੋ।
• ਗੇਟ ਸਥਿਰ ਰਹਿਣ ਮਗਰੋਂ, 25% ਚਰਨਾਂ ਵਿੱਚ ਖਰਚ ਵਧਾਓ।

ਪਾਲਣਾ ਲਈ, ਹਰ ਇਵੈਂਟ ਨਾਲ ਸਹਿਮਤੀ ਹਾਲਤ ਸੰਭਾਲੋ, ਰਾਊਟਿੰਗ ਨਿਯਮ ਬਦਲਾਅ ਨੂੰ ਵਰਜ਼ਨ ਕਰੋ, ਅਤੇ ਰਿਟੈਨਸ਼ਨ ਅਤੇ ਡਿਲੀਸ਼ਨ ਰਸਤੇ ਦਸਤਾਵੇਜ਼ ਕਰੋ। ਪ੍ਰੋਡਕਸ਼ਨ ਸਕੇਲ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੀ ਅੰਦਰੂਨੀ ਪ੍ਰਕਿਰਿਆ Daily Intel Service compliance requirements ਨਾਲ ਮਿਲਾਓ।

Daily Intel Service ਕਿੱਥੇ ਫਿੱਟ ਹੁੰਦਾ ਹੈ

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

ਇਹ ਵਰਕਫਲੋ ਵਿਆਪਕ Daily Intel Service methodology ਦਾ ਹਿੱਸਾ ਹੈ: ਲਾਈਵ ਮਾਰਕੀਟ ਸੰਕੇਤਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ ਅਤੇ ਫਿਰ ਐਸੇ ਟ੍ਰੈਕਿੰਗ ਨਾਲ ਕਾਰਵਾਈ ਕਰੋ ਜੋ ਆਡਿਟ ਅਤੇ ਰਿਕਨਸਿਲੀਏਸ਼ਨ ਝੱਲ ਸਕੇ।

ਵਾਰੰ-ਵਾਰ ਪੁੱਛੇ ਸਵਾਲ

ਪ੍ਰਸ਼ਨ: ਸਰਵਰ-ਸਾਈਡ GTM ਕੀ ਹੈ?
ਜਵਾਬ: ਸਰਵਰ-ਸਾਈਡ GTM ਇੱਕ Google Tag Manager ਸਰਵਰ ਕਨਟੇਨਰ ਹੈ ਜੋ ਨਿਯੰਤਰਿਤ ਐਂਡਪੌਇੰਟ ’ਤੇ ਇਵੈਂਟ ਲੈਂਦਾ ਹੈ, ਉਹਨਾਂ ਦੀ ਪੁਸ਼ਟੀ ਅਤੇ ਤਬਦੀਲੀ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਇਵੈਂਟਾਂ ਨੂੰ Meta CAPI, GA4 ਜਾਂ ਇੱਕ internal warehouse ਵਰਗੇ ਗੰਤੀ-ਸਥਾਨਾਂ ’ਤੇ ਭੇਜਦਾ ਹੈ।

ਪ੍ਰਸ਼ਨ: ਸਰਵਰ-ਸਾਈਡ GTM ਬਰਾਊਜ਼ਰ GTM ਨਾਲ ਕਿਵੇਂ ਵੱਖਰਾ ਹੈ?
ਜਵਾਬ: ਬਰਾਊਜ਼ਰ GTM ਪੰਨੇ ਵਿੱਚ ਚੱਲਦਾ ਹੈ ਅਤੇ ਬਰਾਊਜ਼ਰ ਪਾਬੰਦੀਆਂ, ਐਕਸਟੈਨਸ਼ਨਾਂ ਅਤੇ ਪੰਨਾ-ਪੱਧਰੀ ਗਲਤੀਆਂ ਤੋਂ ਪ੍ਰਭਾਵਿਤ ਹੁੰਦਾ ਹੈ। ਸਰਵਰ-ਸਾਈਡ GTM ਬਰਾਊਜ਼ਰ ਇਵੈਂਟ ਭੇਜਣ ਤੋਂ ਬਾਅਦ ਕੇਂਦਰਿਤ ਤੌਰ ’ਤੇ ਵੈਲਿਡੇਸ਼ਨ, ਡਿਪਲੀਕੇਟ ਹਟਾਉਣਾ, ਸਹਿਮਤੀ ਹੈਂਡਲਿੰਗ ਅਤੇ API ਰਾਊਟਿੰਗ ਕਰਦਾ ਹੈ।

ਪ੍ਰਸ਼ਨ: ਇਕ ਐਫਿਲੀਏਟਰ ਨੂੰ ਸਰਵਰ-ਸਾਈਡ GTM ਕਦੋਂ ਵਰਤਣਾ ਚਾਹੀਦਾ ਹੈ?
ਜਵਾਬ: ਜਦੋਂ ਫਨਲ ਵਿੱਚ ਅਰਥਪੂਰਨ ਟ੍ਰੈਫਿਕ ਹੋਵੇ ਅਤੇ ਟ੍ਰੈਕਿੰਗ ਗੁਣਵੱਤਾ ਫੈਸਲੇ ਨੂੰ ਸੀਮਿਤ ਕਰ ਰਹੀ ਹੋਵੇ। ਜੇ ਆਫਰ ਬਿਨਾਂ ਜਾਂਚਿਆ ਹੋਵੇ ਜਾਂ ਟ੍ਰੈਫਿਕ ਇੰਨਾ ਘੱਟ ਹੋਵੇ ਕਿ ਮੁਲਾਂਕਣ ਨਾ ਹੋ ਸਕੇ, ਤਾਂ SGTM ਦੀ ਜਟਿਲਤਾ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਫਨਲ ਦੀ ਅਰਥਵਿਵਸਥਾ ਠੀਕ ਕਰੋ।

ਪ੍ਰਸ਼ਨ: ਮੈਂ ਕਿਵੇਂ ਜਾਣਾਂ ਕਿ ਸੈਟਅੱਪ ਸਕੇਲ ਕਰਨ ਲਈ ਤਿਆਰ ਹੈ?
ਜਵਾਬ: ਸਕੇਲਿੰਗ ਕੇਵਲ ਉਸ ਵੇਲੇ ਕਰੋ ਜਦੋਂ ਸਕੀਮਾ ਪਾਸ ਰੇਟ, ਡੇਡੂਪ ਸੰਘਰਸ਼, invocation errors, latency ਅਤੇ reconciliation variance ਤੁਹਾਡੇ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਗੇਟਾਂ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ 24 ਤੋਂ 48 ਘੰਟਿਆਂ ਲਈ ਰਹਿੰਦੇ ਹੋਣ।

ਪ੍ਰਸ਼ਨ: ਕੀ ਸਰਵਰ-ਸਾਈਡ GTM ਆਪਣੇ ਆਪ Meta CAPI ਨਤੀਜੇ ਸੁਧਾਰਦਾ ਹੈ?
ਜਵਾਬ: ਨਹੀਂ। ਇਹ ਡਿਲੀਵਰੀ ਅਤੇ ਸਥਿਰਤਾ ਨੂੰ ਸੁਧਾਰ ਸਕਦਾ ਹੈ ਜੇ ਇਵੈਂਟ ID, ਸਹਿਮਤੀ ਹਾਲਤ, ਪਛਾਣਕਾਰ ਅਤੇ ਸਰੋਤ ਫੀਲਡ ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਲਾਗੂ ਕੀਤੇ ਜਾਣ, ਪਰ ਨਤੀਜੇ ਟ੍ਰੈਫਿਕ ਗੁਣਵੱਤਾ, ਸਹਿਮਤੀ ਕਵਰੇਜ, ਬਰਾਊਜ਼ਰ ਇਵੈਂਟ ਅਤੇ ਆਫਰ-ਬੈਕਐਂਡ ਦੀ ਸਹੀਤਾ ’ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ।