ਕੂਕੀ ਬਦਲਾਵਾਂ ਤੋਂ ਬਾਅਦ ਸਾਂਝੇਦਾਰੀ ਅਟ੍ਰੀਬਿਊਸ਼ਨ ਨੂੰ ਕਿਵੇਂ ਠੀਕ ਕਰੀਏ

ਕੂਕੀ ਪਾਬੰਦੀਆਂ ਤੋਂ ਬਾਅਦ ਸਾਂਝੇਦਾਰੀ ਅਟ੍ਰੀਬਿਊਸ਼ਨ ਕਿਉਂ ਟੁੱਟਦੀ ਹੈ

ਕੂਕੀਆਂ ਹੁਣ ਪੂਰੇ ਖਰੀਦਦਾਰ ਰਸਤੇ ਨੂੰ ਨਹੀਂ ਕਵਰ ਕਰਦੀਆਂ

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

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

ਹਰ ਸਿਸਟਮ ਰੂਪਾਂਤਰਨ ਨੂੰ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਗਿਣਦਾ ਹੈ

ਸਾਂਝੇਦਾਰੀ ਨੈੱਟਵਰਕ, ਇਸ਼ਤਿਹਾਰ ਪਲੇਟਫਾਰਮ, ਵਿਸ਼ਲੇਸ਼ਣ ਸਾਧਨ ਅਤੇ ਵਪਾਰੀ ਪ੍ਰੋਸੈਸਰ ਵੱਖ-ਵੱਖ ਸਮੇਂ ਦੀਆਂ ਮੁਹਰਾਂ, ਸਥਿਤੀਆਂ, ਨਕਲ-ਰੋਕ ਨਿਯਮ ਅਤੇ ਮਨਜ਼ੂਰੀ ਤਰਕ ਵਰਤਦੇ ਹਨ। ਇੱਕ ਰਿਪੋਰਟ ਵਿੱਚ ਕੋਈ ਵਿਕਰੀ ਲੰਬਿਤ (pending) ਦਿਖ ਸਕਦੀ ਹੈ ਜਦਕਿ ਵਪਾਰੀ ਲੈਜਰ ਵਿੱਚ ਅਜੇ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਵਿਕਰੀ ਹੀ ਨਹੀਂ। ਦੂਜੀ ਰਿਪੋਰਟ ਦੇਰੀ ਨਾਲ ਆਏ ਪੋਸਟਬੈਕ ਕਾਰਨ ਆਮਦਨ ਨੂੰ ਵੱਖਰੇ ਦਿਨ ਵਿੱਚ ਵਾਪਸ ਲਿਖ ਸਕਦੀ ਹੈ।

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

ਰਿਵਰਸਲ ਅਟ੍ਰੀਬਿਊਸ਼ਨ ਦਾ ਹਿੱਸਾ ਹੈ, ਸਿਰਫ਼ ਹਿਸਾਬ-ਕਿਤਾਬ ਦੀ ਟਿੱਪਣੀ ਨਹੀਂ

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

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

ਕਦਮ 1: ਮਿਆਰੀ ਘਟਨਾ ਕਰਾਰ ਬਣਾਓ

ਘੱਟ ਤੋਂ ਘੱਟ ਕਾਰਗਰ ਘਟਨਾ ਸੈੱਟ ਨਿਰਧਾਰਤ ਕਰੋ

ਘਟਨਾ ਕਰਾਰ ਉਹ ਸਾਂਝੀ ਪਰਿਭਾਸ਼ਾ ਹੈ ਜੋ ਦੱਸਦੀ ਹੈ ਕਿ ਹਰ ਟਰੈਕ ਕੀਤੀ ਘਟਨਾ ਦਾ ਮਤਲਬ ਕੀ ਹੈ, ਇਹ ਕਦੋਂ ਚਲਦੀ ਹੈ ਅਤੇ ਕਿਹੜੇ ਖੇਤਰ ਲਾਜ਼ਮੀ ਹਨ। ਇਸ ਦੇ ਬਿਨਾਂ ਇੱਕ ਟੀਮ ਵਿਕਰੀ ਨੂੰ purchase ਕਹਿ ਸਕਦੀ ਹੈ, ਦੂਜੀ conversion ਅਤੇ ਕੋਈ ਨੈੱਟਵਰਕ transaction_approved ਕਹਿ ਸਕਦਾ ਹੈ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਛੋਟਾ ਅਤੇ ਵਰਜਨਸ਼ੁਦਾ ਘਟਨਾ ਸੈੱਟ ਵਰਤੋ:

• click_handoff
• landing_view
• lead_capture
• checkout_init
• transaction_pending
• transaction_approved
• transaction_reversed
• payout_calculated

ਹਰ ਘਟਨਾ ਵਿੱਚ UTC ਸਮੇਂ ਦੀ ਮੁਹਰ, ਸਰੋਤ, ਕੈਂਪੇਨ, ਲਾਗੂ ਹੋਣ 'ਤੇ ਸਾਂਝੇਦਾਰ ID, ਕਲਿੱਕ ID, ਪੇਸ਼ਕਸ਼ ID, ਫਨਲ ਕਦਮ ਅਤੇ ਘਟਨਾ ਵਰਜਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਿਰਫ਼ ਉਹੀ ਵਿਕਲਪਿਕ ਫੀਲਡ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਅਸਲੀ ਫੈਸਲੇ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹੋਣ।

ਕਲਿੱਕ ਤੋਂ ਭੁਗਤਾਨ ਤੱਕ ਪਛਾਣ ਜਾਰੀ ਰੱਖੋ

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

ਘੱਟੋ-ਘੱਟ ਇਹ ਖੇਤਰ ਸੰਭਾਲੋ:

• ਸਰੋਤ ਕਲਿੱਕ ਪਛਾਣ ਨੰਬਰ, ਜਿਵੇਂ fbclid, gclid, ttclid, ਜਾਂ ਉਪਲਬਧ ਹੋਣ 'ਤੇ ਨੈੱਟਵਰਕ ਕਲਿੱਕ ID
• ਪਹਿਲੇ ਸੰਪਰਕ 'ਤੇ ਬਣਾਇਆ ਗਿਆ ਅੰਦਰੂਨੀ click_id
• affiliate_id, sub_id, campaign_id, ਅਤੇ offer_id
• UTC ਵਿੱਚ ਨਾ ਬਦਲਣਯੋਗ ਪਹਿਲਾ-ਸਪਰਸ਼ ਸਮਾਂ-ਮੁਹਰ
• ਲੈਂਡਿੰਗ URL, ਜਿਥੇ ਸਹਿਮਤੀ ਅਤੇ ਨੀਤੀ ਇਜਾਜ਼ਤ ਦੇਵੇ ਉਥੇ referrer ਅਤੇ UTM ਮੁੱਲ

ਜਦ ਅਡ ਟੂ ਐਡ ਲਿੰਕ ਤੋਂ ਵਪਾਰੀ ਘਟਨਾ ਤੱਕ ਪਛਾਣ ਨੰਬਰ ਬਦਲ ਜਾਵੇ ਤਾਂ ਮੁਹਿੰਮ ਦੀ ਸਹੀ ਜਾਂਚ ਨਹੀਂ ਹੋ ਸਕਦੀ। ਜਿੱਥੇ ਫੀਲਡ ਬਦਲਣੀ ਪਵੇ, ਉੱਥੇ ਪੁਰਾਣਾ ਮੁੱਲ, ਨਵਾਂ ਮੁੱਲ, ਸਮੇਂ ਦੀ ਮੁਹਰ ਅਤੇ ਰੂਪਾਂਤਰਨ ਨਿਯਮ ਲੋਗ ਕਰੋ।

ਮਿਲਾਪ ਤੋਂ ਪਹਿਲਾਂ ਨਕਲ ਘਟਾਓ

ਦੁਹਰਾਈ ਵਿਕਰੀਆਂ ਆਮ ਤੌਰ 'ਤੇ webhook ਦੁਬਾਰਾ ਕਾਲਾਂ, ਬਰਾਊਜ਼ਰ ਰੀਫਰੈਸ਼, ਸਰਵਰ ਟਾਈਮਆਉਟ ਅਤੇ ਪੋਸਟਬੈਕ ਦੁਹਰਾਈ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ। ਨਕਲ ਹਟਾਉਣਾ ਭੁਗਤਾਨ ਜਾਂ ਬਜਟ ਫੈਸਲੇ ਲਈ ਆਮਦਨ ਵਰਤਣ ਤੋਂ ਪਹਿਲਾਂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਇੱਕ ਵਿਹਾਰਕ dedupe ਕੁੰਜੀ order_id + affiliate_id + amount + event_type ਹੈ; ਕੇਵਲ ਉਹਥੇ ਅਲੱਗ ਦਿਨ ਵਾਲਾ bucket ਵਰਤੋ ਜਦ ਕ੍ਰਮ ਨੰਬਰ ਅਵਿਸ਼ਵਾਸਯੋਗ ਹੋਣ। ਸਥਿਰ ਸਿਸਟਮਾਂ ਵਿੱਚ 3% ਤੋਂ ਵੱਧ ਅੰਦਾਜ਼ੇਸ਼ੁਦਾ ਦੁਹਰਾਈ ਵਿਕਰੀ ਅਨੁਪਾਤ ਜਾਂਚ ਮੰਗਦਾ ਹੈ, ਅਤੇ 5% ਤੋਂ ਉੱਪਰ ਹੋਣ 'ਤੇ ਆਮ ਤੌਰ 'ਤੇ ਸਰੋਤ ਪਛਾਣ ਹੋਣ ਤੱਕ ਆਟੋਮੈਟਿਕ ਸਕੇਲਿੰਗ ਰੋਕ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ।

ਕਦਮ 2: ਪਲੇਟਫਾਰਮ ਰਿਪੋਰਟਾਂ ਨੂੰ ਵਪਾਰੀ ਸੱਚਾਈ ਨਾਲ ਮਿਲਾਓ

ਰੋਜ਼ਾਨਾ ਦਿਨ-ਅੰਤ ਲੈਜਰ ਤਿਆਰ ਕਰੋ

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

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

ਕੁੱਲ ਨਾਲ ਨਹੀਂ, ਸਰੋਤ ਅਨੁਸਾਰ ਦਲਟ ਦੀ ਤੁਲਨਾ ਕਰੋ

ਕੁੱਲ ਆਮਦਨ ਕਾਫੀ ਕਰੀਬ ਲੱਗ ਸਕਦੀ ਹੈ ਪਰ ਵਿਅਕਤੀਗਤ ਸਰੋਤ ਗੰਭੀਰਤਾ ਨਾਲ ਗਲਤ-ਅਟ੍ਰੀਬਿਊਟ ਹੋ ਸਕਦੇ ਹਨ। ਹਰ ਸਰੋਤ ਨਾਲ ਸੌਖਾ ਦਲਟ ਵੇਖੋ: ਪਲੇਟਫਾਰਮ-ਅਟ੍ਰੀਬਿਊਟ ਕੀਤੀ ਆਮਦਨ ਵਿੱਚੋਂ ਤੁਹਾਡੇ ਕ੍ਰੈਡਿਟ ਨਿਯਮ ਲਾਗੂ ਹੋਣ ਤੋਂ ਬਾਅਦ ਵਪਾਰੀ-ਮਨਜ਼ੂਰ ਆਮਦਨ ਘਟਾਓ।

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

ਰਿਪੋਰਟਿੰਗ ਕੱਟਾਂ ਨੂੰ ਇੱਕੋ ਜਿਹਾ ਕਰੋ

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

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

ਕਦਮ 3: ਖਰੀਦਦਾਰ ਵਰਤਾਰਿਆਂ ਅਨੁਸਾਰ ਲੁੱਕਬੈਕ ਅਵਧੀਆਂ ਸੰਭਾਰੋ

ਖਰੀਦ ਚੱਕਰ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ

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

ਤੇਜ਼ ਸਾਂਝੇਦਾਰੀ ਫਨਲ ਅਕਸਰ 24 ਤੋਂ 72 ਘੰਟਿਆਂ ਵਿੱਚ ਰੂਪਾਂਤਰਿਤ ਹੁੰਦੇ ਹਨ। ਵਧੇਰੇ ਸੋਚ-ਵਿਚਾਰ ਵਾਲੀਆਂ ਪੇਸ਼ਕਸ਼ਾਂ, ਵਿੱਤੀ ਉਤਪਾਦ, ਸਿੱਖਿਆ, ਸਾਫਟਵੇਅਰ ਅਤੇ ਸਿਹਤ-ਸਬੰਧੀ ਫਨਲਾਂ ਵਿੱਚ 7 ਤੋਂ 30 ਦਿਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ, ਜੋ ਤੁਹਾਡੀ ਆਪਣੀ ਡਾਟਾ ਵਿੱਚ ਦਿੱਸਦੇ ਅਪਣੇ-ਅਪਣੇ ਪੱਧਰ ਦੇ ਭਰੋਸੇਯੋਗ ਸਮਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ।

ਹਰ ਵਾਰੀ ਇੱਕੋ ਸਮੇਂ ਇੱਕ ਵਿੰਡੋ ਹੀ ਬਦਲੋ ਅਤੇ ਨਿਯੰਤਰਣ ਨਜ਼ਰੀਆ ਚਾਲੂ ਰੱਖੋ। ਜੇ ਵਿੰਡੋ ਬਦਲਣ ਤੋਂ ਇੱਕ ਹਫ਼ਤੇ ਬਾਅਦ ਰਿਪੋਰਟ ਕੀਤੇ ਲਾਭ 20% ਤੋਂ 30% ਤੱਕ ਬਦਲਣ, ਤਾਂ ਸਕੇਲਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚ ਕਰੋ।

ਬਹੁਤ ਲੰਬੀਆਂ ਅਵਧੀਆਂ ਨੂੰ ਕਮਜ਼ੋਰ ਵਾਧੂ ਯੋਗਦਾਨ ਨਹੀਂ ਲੁਕਾਉਣਾ ਚਾਹੀਦਾ

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

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

ਕਦਮ 4: ਸੁਰੱਖਿਅਤ ਪਾਬੰਦੀਆਂ ਨਾਲ ਡੇਟਾ-ਅਧਾਰਿਤ ਅਟ੍ਰੀਬਿਊਸ਼ਨ ਵਰਤੋ

ਉੱਨਤ ਮਾਡਲਾਂ ਤੋਂ ਪਹਿਲਾਂ ਇਨਪੁਟ ਸਾਫ਼ ਕਰੋ

ਡੇਟਾ-ਅਧਾਰਿਤ ਅਟ੍ਰੀਬਿਊਸ਼ਨ ਵੱਡੇ ਭਰਾਵਾਂ ਅਤੇ ਸਥਿਰ ਘਟਨਾ-ਗੁਣਵੱਤਾ ਹੋਣ 'ਤੇ ਲਾਭਕਾਰੀ ਹੋ ਸਕਦੀ ਹੈ। ਇਹ ਗੁੰਮ ਕਲਿੱਕ ID, ਦੁਹਰਾਏ ਪੋਸਟਬੈਕ, ਟੁੱਟੇ UTM ਜਾਂ ਅਸਥਿਰ ਲੈਣ-ਦੇਣ ਸਥਿਤੀ ਲਈ ਮਰੰਮਕ ਸੰਦ ਨਹੀਂ ਹੈ।

ਕੋਈ ਵੀ ਐਲਗੋਰਿਦਮਿਕ ਮਾਡਲ ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਆਖਰੀ ਕਲਿੱਕ ਜਾਂ ਰੇਖੀ (linear) ਵਰਗਾ ਨਿਯੰਤਰਣ ਮਾਡਲ ਨਾਲ-ਨਾਲ ਚਲਾਓ। ਜੇ ਦੋਵੇਂ ਮਾਡਲ 7 ਤੋਂ 14 ਦਿਨ ਤੱਕ ਇੱਕੋ ਦਿਸ਼ਾ ਵਿੱਚ ਸਰੋਤਾਂ ਨੂੰ ਰੈਂਕ ਕਰ ਰਹੇ ਹਨ, ਤਾਂ ਸੰਕੇਤ ਵੱਧ ਭਰੋਸੇਯੋਗ ਹੁੰਦਾ ਹੈ। ਜੇ ਕਿਸੇ ਇੱਕ ਸਰੋਤ ਲਈ ਉਹ 25% ਤੋਂ ਵੱਧ ਫਰਕ ਦਿਖਾਉਣ, ਤਾਂ ਸਕੇਲਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਉਸ ਸਰੋਤ ਦੀ ਜਾਂਚ ਕਰੋ।

Google ਇਹ ਗੱਲ Google Ads attribution documentation ਵਿੱਚ ਸਮਝਾਉਂਦਾ ਹੈ। ਉਸ ਪਲੇਟਫਾਰਮ ਦੀ ਰਹਿਨੁਮਾ ਨੂੰ ਮਾਡਲ ਸੰਦਰਭ ਵਜੋਂ ਲਓ, ਫਿਰ ਵਪਾਰੀ-ਮਨਜ਼ੂਰ ਅਤੇ ਰਿਵਰਸਲ-ਸੋਧੇ ਡਾਟਾ ਨਾਲ ਸਤਿਆਪਨ ਕਰੋ।

ਇੱਕੋ ਦਿਨ ਦੇ ਬਜਟ ਪ੍ਰਤੀਕਿਰਿਆ ਤੋਂ ਬਚੋ

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

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

ਕਦਮ 5: ਟਰੈਕਿੰਗ, ਅਨੁਸਾਰਤਾ ਅਤੇ ਮੁਹਿੰਮ ਵਰਗੀਕਰਨ ਮਜ਼ਬੂਤ ਕਰੋ

ਸਰਵਰ-ਸਾਈਡ ਕੈਪਚਰ ਨੂੰ ਲਚੀਲੀ ਪਰਤ ਵਜੋਂ ਵਰਤੋ

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

ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ, Meta ਦੀ Conversions API documentation ਵਰਗੇ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਪਲੇਟਫਾਰਮ ਮਕੈਨਿਜ਼ਮ ਰਾਹੀਂ ਸਾਫ਼ ਰੂਪਾਂਤਰਨ ਘਟਨਾਵਾਂ ਭੇਜੋ ਅਤੇ ਕਾਨੂੰਨੀ ਤੇ ਪਲੇਟਫਾਰਮ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਅਨੁਸਾਰ ਸਹਿਮਤੀ ਰਿਕਾਰਡ ਸੰਭਾਲੋ।

UTMs ਨੂੰ ਸਖ਼ਤ ਅਤੇ ਪੜ੍ਹਨਯੋਗ ਰੱਖੋ

UTM ਫੀਲਡਾਂ ਬੋਰਿੰਗ, ਇਕਸਾਰ ਅਤੇ ਆਸਾਨੀ ਨਾਲ ਜੋੜਯੋਗ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। utm_source, utm_medium, ਅਤੇ utm_campaign ਨੂੰ ਲਾਜ਼ਮੀ ਬਣਾਓ; utm_content ਨੂੰ ਸਿਰਫ਼ ਰਚਨਾਤਮਕ ਜਾਂ ਕੋਣ ਲਈ ਰੱਖੋ; ਅਤੇ utm_term ਤਦ ਹੀ ਵਰਤੋ ਜਦ ਇਹ ਅਸਲ ਮਾਇਨੇਦਾਰ ਖੋਜ-ਸ਼ਬਦ, ਕੀਵਰਡ ਜਾਂ ਸੈਗਮੈਂਟ ਜਾਣਕਾਰੀ ਲੈ ਕੇ ਜਾਵੇ।

ਜਦ ਮੁਹਿੰਮ ਨਾਮਕਰਨ ਦੀ ਜਾਂਚ ਕਰਨਾ ਔਖਾ ਹੋ ਜਾਵੇ ਤਾਂ UTM decoding guidance ਵਰਤੋ। ਖਰਚਾ ਪਹਿਲਾਂ ਹੀ ਮੁੜ ਚੱਲ ਜਾਣ ਤੋਂ ਬਾਅਦ ਹੱਥੋਂ ਸਫ਼ਾਈ ਕਰਨ ਦੀ ਥਾਂ ਦਾਖ਼ਲਾ ਪੱਧਰ 'ਤੇ ਹੀ ਖਰਾਬ ਮੁਹਿੰਮਾਂ ਰੱਦ ਕਰੋ।

ਕੈਂਪੇਨ ਬਦਲਾਵਾਂ ਨਾਲ ਅਨੁਸਾਰਤਾ ਸਬੂਤ ਜੋੜੋ

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

Google ਦੀ helpful content guidance ਅੰਦਰੂਨੀ ਸੰਪਾਦਕੀ ਜਾਂਚ ਲਈ ਵੀ ਲਾਭਕਾਰੀ ਹੈ: ਸਮੱਗਰੀ ਅਤੇ ਰਿਪੋਰਟ ਪਾਰਦਰਸ਼ੀ, ਅਪਡੇਟ ਹੋਣਯੋਗ ਅਤੇ ਪਾਠਕ ਕੇਂਦ੍ਰਿਤ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਖੋਜ ਇੰਜਨਾਂ ਲਈ ਭਰੀ ਗਈ। ਅੰਦਰੂਨੀ ਸਮੀਖਿਆ ਲਈ, ਅਸਥਿਰ ਸਰੋਤਾਂ ਦੇ ਸਕੇਲਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਕੋਈ ਵੀ ਵੱਡਾ ਖਰਚ compliance requirements ਨਾਲ ਜੋੜ ਕੇ ਦੇਖੋ।

30-ਦਿਨੀ ਸਾਂਝੇਦਾਰੀ ਅਟ੍ਰੀਬਿਊਸ਼ਨ ਮਰੰਮ ਰਨਬੁੱਕ

ਹਫ਼ਤਾ 1: ਰਿਸਾਅ ਰੋਕੋ

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

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

ਹਫ਼ਤਾ 2: ਲੈਜਰ ਬਣਾਓ

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

ਸਿਰਫ਼ ਕੁੱਲ ਤੋਂ ਅਪਟੀਮਾਈਜ਼ ਨਾ ਕਰੋ। ਸਭ ਤੋਂ ਵੱਡੇ ਅਣਵਿਆਖਿਆ ਦਲਟ ਵਾਲੇ ਸਰੋਤ ਲੱਭੋ ਅਤੇ ਅਟ੍ਰੀਬਿਊਸ਼ਨ ਮਾਡਲ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹਨਾਂ ਨੂੰ ਠੀਕ ਕਰੋ।

ਹਫ਼ਤਾ 3: ਅਟ੍ਰੀਬਿਊਸ਼ਨ ਸੈਟਿੰਗਾਂ ਦੀ ਟੈਸਟਿੰਗ ਕਰੋ

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

ਜੇ ਟੈਸਟ ਰਿਪੋਰਟ ਕੀਤੀ ROI ਸੁਧਾਰੇ ਪਰ ਵਪਾਰੀ-ਮਨਜ਼ੂਰ ਸ਼ੁੱਧ ਆਮਦਨ ਨਹੀਂ ਵਧੇ, ਤਾਂ ਇਸਨੂੰ ਰਿਪੋਰਟਿੰਗ ਬਦਲਾਅ ਵਜੋਂ ਸਮਝੋ, ਕਾਰਗੁਜ਼ਾਰੀ ਸੁਧਾਰ ਨਹੀਂ।

ਹਫ਼ਤਾ 4: ਸਿਰਫ਼ ਜਿੱਥੇ ਗੁਣਵੱਤਾ ਥਿਰ ਹੋਵੇ ਉੱਥੇ ਹੀ ਸਕੇਲ ਕਰੋ

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

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

ਅਕਸਰ ਪੁੱਛੇ ਸਵਾਲ

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

ਸਵਾਲ: ਸਾਂਝੇਦਾਰੀ ਅਟ੍ਰੀਬਿਊਸ਼ਨ ਵਿੰਡੋ ਕਿੰਨੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ?
ਜਵਾਬ: ਸਭ ਤੋਂ ਛੋਟੀ ਉਹ ਵਿੰਡੋ ਵਰਤੋ ਜੋ ਵੇਖੀ ਗਈ ਖਰੀਦਦਾਰ ਵਰਤੋਂ ਨਾਲ ਮਿਲਦੀ ਹੋਵੇ। ਕਈ ਤੇਜ਼-ਪ੍ਰਤੀਕਿਰਿਆ ਫਨਲ 1 ਤੋਂ 7 ਦਿਨਾਂ ਵਿੱਚ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ, ਜਦਕਿ ਵਧੇਰੇ ਸੋਚ-ਵਿਚਾਰ ਵਾਲੀਆਂ ਪੇਸ਼ਕਸ਼ਾਂ ਨੂੰ 14 ਤੋਂ 30 ਦਿਨਾਂ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ ਜੇ ਤੁਹਾਡੇ ਆਪਣੇ ਡਾਟਾ ਵਿੱਚ ਲੰਮਾ ਰਸਤਾ ਦਿੱਸਦਾ ਹੋਵੇ।

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

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

ਸਵਾਲ: ਅਟ੍ਰੀਬਿਊਸ਼ਨ ਠੀਕ ਕਰਨ ਤੋਂ ਬਾਅਦ ਸਕੇਲਿੰਗ ਲਈ ਕਦੋਂ ਸੁਰੱਖਿਅਤ ਹੈ?
ਜਵਾਬ: ਘੱਟੋ-ਘੱਟ 7 ਤੋਂ 14 ਦਿਨ ਸਥਿਰ ਡਾਟਾ ਦੀ ਉਡੀਕ ਕਰੋ, ਜੋ ਵਾਲੀਅਮ ਅਤੇ ਰਿਵਰਸਲ ਵਿਲੰਬ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਕੇਵਲ ਤਦ ਹੀ ਸਕੇਲਿੰਗ ਕਰੋ ਜਦੋਂ ਮੇਲ ਦਰ, ਦੁਹਰਾਈ ਦਰ, ਪੋਸਟਬੈਕ ਵਿਲੰਬ ਅਤੇ ਰਿਵਰਸਲ-ਸੋਧੀ ROI ਸਭ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਸੀਮਾਵਾਂ ਵਿੱਚ ਰਹਿਣ।