ਜਾਣੋ ਕਿ Uber-ਜਿਹੇ ਪਲੇਟਫਾਰਮ ਕਿਵੇਂ ਲਿਕਵਿਡਿਟੀ, ਡਾਇਨਾਮਿਕ ਪ੍ਰਾਇਸਿੰਗ ਅਤੇ ਡਿਸਪੈਚ ਕੋਆਰਡੀਨੇਸ਼ਨ ਨਾਲ ਪੂਰਤੀ-ਮੰਗ ਨੂੰ ਸੰਤੁਲਿਤ ਕਰਦੇ ਹਨ ਤਾਂ ਜੋ ਸ਼ਹਿਰ ਦੀ ਮੋਬਿਲਿਟੀ ਪ੍ਰੋਗ੍ਰਾਮੇਬਲ ਮਹਿਸੂਸ ਹੋਵੇ।
ਇੱਕ ਸ਼ਹਿਰ ਸੋਫਟਵੇਅਰ ਨਹੀਂ ਹੈ—ਪਰ ਜਦੋਂ ਕੋਈ ਪਲੇਟਫਾਰਮ ਜੋ ਕੁਝ ਹੋ ਰਿਹਾ ਹੈ 'ਸੈਂਸ' ਕਰ ਸਕਦਾ, ਨਿਯਮ ਲਗਾ ਸਕਦਾ ਅਤੇ ਨਤੀਜਿਆਂ ਤੋਂ ਸਿੱਖ ਸਕਦਾ ਹੈ, ਤਾਂ ਉਸ ਦੇ ਹਲਕੇ ਤੱਤਾਂ ਨੂੰ ਸੋਫਟਵੇਅਰ ਵਾਂਗ ਪ੍ਰਵਰਤਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਇਸ ਅਰਥ ਵਿੱਚ, “ਪ੍ਰੋਗ੍ਰਾਮੇਬਲ” ਦਾ ਮਤਲਬ ਸ਼ਹਿਰ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਨਾ ਨਹੀਂ ਹੈ। ਇਹ ਮਤਲਬ ਹੈ ਉਸ 'ਤੇ ਇੱਕ ਲਗਾਤਾਰ ਅੱਪਡੇਟ ਹੋਣ ਵਾਲੀ ਕੋਆਰਡੀਨੇਸ਼ਨ ਪਰਤ ਚਲਾਉਣਾ।
ਇੱਕ ਪ੍ਰੋਗ੍ਰਾਮੇਬਲ ਨੈੱਟਵਰਕ ਉਹ ਸਿਸਟਮ ਹੈ ਜਿੱਥੇ:
Uber ਇੱਕ ਸਾਫ਼ ਉਦਾਹਰਣ ਹੈ ਕਿਉਂਕਿ ਇਹ ਗੰਦੇ ਸ਼ਹਿਰੀ ਹਕੀਕਤ ਨੂੰ ਮਸ਼ੀਨ-ਪਾਠਯੋਗ ਸੰਕੇਤਾਂ ਵਿੱਚ ਲਗਾਤਾਰ ਤਬਦੀਲ ਕਰਦਾ, ਹਜ਼ਾਰਾਂ ਛੋਟੇ ਫੈਸਲੇ ਲੈਂਦਾ, ਅਤੇ ਜਦੋਂ ਨਵੇਂ ਸੰਕੇਤ ਆਉਂਦੇ ਹਨ ਤਾਂ ਉਹਨਾਂ ਫੈਸਲਿਆਂ ਨੂੰ ਅਪਡੇਟ ਕਰਦਾ ਹੈ।
ਕੋਆਰਡੀਨੇਸ਼ਨ ਮੁਸ਼ਕਲ ਹੈ ਕਿਉਂਕਿ “ਇਨਪੁਟ” ਅਸਥਿਰ ਅਤੇ ਹਿੱਸੇ-ਤਰ੍ਹਾਂ ਮਨੁੱਖੀ ਹੁੰਦੇ ਹਨ।
ਟ੍ਰੈਫਿਕ ਮਿੰਟਾਂ ਵਿੱਚ ਸੁਚੱਜੀ ਹਾਲਤ ਤੋਂ ਬੰਦ-ਮੁੜੀ ਗ੍ਰਿਡਲਾਕ ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਹੈ। ਮੌਸਮ ਮੰਗ ਅਤੇ ਡ੍ਰਾਈਵਿੰਗ ਗਤੀ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਕਾਨਸਰਟ, ਖੇਡਾਂ, ਸਬਵੇ ਡੀਲੇ, ਅਤੇ ਰੋਡ ਬੰਦਸ਼ sudden spikes ਬਣਾਉਂਦੇ ਹਨ। ਅਤੇ ਲੋਕ ਸੈਂਸਰਾਂ ਵਾਂਗ ਨਹੀਂ ਵਰਤਦੇ—ਉਹ ਕੀਮਤਾਂ, ਉਡੀਕ ਸਮੇਂ, ਪ੍ਰੋਤਸਾਹਨਾਂ ਅਤੇ ਆਦਤਾਂ ਦੇ ਅਨੁਸਾਰ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਦੇ ਹਨ।
ਇਸ ਲਈ ਚੁਨੌਤੀ ਸਿਰਫ਼ ਇਹ ਪੇਸ਼ਗੋਈ ਨਹੀਂ ਹੈ ਕਿ ਕੀ ਹੋਵੇਗਾ; ਇਹ ਕਾਫੀ ਤੇਜ਼ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਨ ਦੀ ਵੀ ਹੈ ਤਾਂ ਕਿ ਪ੍ਰਤੀਕਿਰਿਆ ਖੁਦ ਨਵੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨਾ ਪੈਦਾ ਕਰੇ।
ਜਦੋਂ ਲੋਕ ਕਹਿੰਦੇ ਹਨ Uber “ਸ਼ਹਿਰ ਨੂੰ ਪ੍ਰੋਗ੍ਰਾਮ ਕਰਦਾ ਹੈ,” ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਮਤਲਬ ਲੈਂਦੇ ਹਨ ਕਿ ਇਹ ਮਾਰਕੀਟਪਲੇਸ ਨੂੰ ਚਲਾਉਣ ਲਈ ਤਿੰਨ ਲੀਵਰ ਵਰਤਦਾ ਹੈ:
ਇਹਨਾਂ ਤਿੰਨਾਂ ਨਾਲ ਵਿਖਰੇ ਹੋਏ ਵਿਅਕਤਗਤ ਫੈਸਲੇ ਇਕ ਸੰਯੋਜਿਤ ਧਾਰ ਵਿੱਚ ਬਦਲਦੇ ਹਨ।
ਇਹ ਲੇਖ ਧਾਰਣਾ ਅਤੇ ਤਕਨੀਕਾਂ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਹੈ: ਲਿਕਵਿਡਿਟੀ, ਡਾਇਨਾਮਿਕ ਪ੍ਰਾਇਸਿੰਗ, ਮੇਚਿੰਗ ਅਤੇ ਫੀਡਬੈਕ ਲੂਪਾਂ ਦੇ ਮੂਲ ਤਰਕ।
ਇਹ ਪ੍ਰੋਪ੍ਰਾਇਟਰੀ ਕੋਡ, ਨਿੱਜੀ ਫਾਰਮੂਲੇ, ਜਾਂ ਅੰਦਰੂਨੀ ਇੰਪਲੀਮੇਂਟੇਸ਼ਨ ਵੇਰਵੇ ਨਹੀਂ ਦੱਸੇਗਾ। ਇਸਨੂੰ ਇੱਕ ਪੁਨਰ-ਵਰਤੋਂਯੋਗ ਮਾਡਲ ਵਜੋਂ ਸੋਚੋ ਜੋ ਇਹ ਸਮਝਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਕਿ ਪਲੇਟਫਾਰਮ ਵੱਡੇ ਸ਼ਹਿਰੀ ਸੇਵਾਵਾਂ ਨੂੰ ਕਿਵੇਂ ਕੋਆਰਡੀਨੇਟ ਕਰਦੇ ਹਨ।
Uber "ਟੈਕਸੀ ਐਪ" ਤੋਂ ਵੱਧ ਹੈ — ਇਹ ਦੋ ਵੱਖ-ਵੱਖ ਲਕੜੀਆਂ ਵਾਲੇ ਗਰੁੱਪਾਂ ਨੂੰ ਕੋਆਰਡੀਨੇਟ ਕਰਨ ਵਾਲਾ ਦੋ-ਪੱਖੀ ਮਾਰਕੀਟਪਲੇਸ ਹੈ: ਯਾਤਰੀ ਜੋ ਹੁਣ ਟ੍ਰਿਪ ਚਾਹੁੰਦੇ ਹਨ, ਅਤੇ ਡ੍ਰਾਈਵਰ ਜੋ ਲਾਭਕਾਰੀ, ਪੇਸ਼ਗੋਇਤ ਕੰਮ ਚਾਹੁੰਦੇ ਹਨ। ਪਲੇਟਫਾਰਮ ਦਾ ਕੰਮ ਹਜ਼ਾਰਾਂ ਵੱਖ-ਵੱਖ ਚੋਈਸਾਂ ਨੂੰ—ਰਿਕਵੇਸਟ ਕਰਨਾ, ਕਬੂਲ ਕਰਨਾ, ਉਡੀਕ, ਰੱਦ ਕਰਨਾ—ਇੱਕ ਸਥਿਰ ਧਾਰ ਵਿੱਚ ਤਬਦੀਲ ਕਰਨਾ ਹੈ।
ਅਧਿਕਤਰ ਯਾਤਰੀਆਂ ਲਈ ਤਜਰਬਾ ਕਾਰ ਖੁਦ ਨਾਲ ਨਹੀਂ ਪਰਿਭਾਸ਼ਿਤ ਹੁੰਦਾ। ਇਹ ਇਸ ਨਾਲ ਪਰਿਭਾਸ਼ਿਤ ਹੁੰਦਾ ਹੈ ਕਿ ਉਹ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਮੇਚ ਹੁੰਦੇ ਹਨ ਅਤੇ ਕਿੰਨੀ ਪੱਕੀ ਪਿਕਅਪ ਹੋਵੇਗੀ। ਪਿਕਅਪ ਤੱਕ ਦਾ ਸਮਾਂ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ (ਰੱਦ ਨਾ ਹੋਣਾ, ETA ਨਾ ਡਿੱਗਣਾ-ਚੜ੍ਹਨਾ) ਆਮ ਤੌਰ 'ਤੇ ਉਹ ਪ੍ਰੈਕਟੀਕਲ "ਉਤਪਾਦ" ਹਨ।
ਇਸ ਲਈ ਲਿਕਵਿਡਿਟੀ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਜਦੋਂ ਕਾਫੀ ਉਪਲਬਧ ਡ੍ਰਾਈਵਰ ਨੇੜੇ ਹੁੰਦੇ ਹਨ, ਸਿਸਟਮ ਤੇਜ਼ੀ ਨਾਲ ਮੇਚ ਕਰ ਸਕਦੀ ਹੈ, ETA ਸਥਿਰ ਰੱਖ ਸਕਦੀ ਹੈ, ਅਤੇ ਰੱਦ-ਕਿਰਿਆਵਾਂ ਘੱਟ ਹੋਣ।
ਹਰ ਮੇਚ ਕਈ ਮੁਕਾਬਲੀ ਨਤੀਜਿਆਂ ਵਿੱਚ ਸੰਤੁਲਨ ਹੈ:
ਇਨ੍ਹਾਂ ਟਰੇਡ-ਆਫ਼ਾਂ ਨੂੰ ਸੰਭਾਲਣ ਲਈ, ਪਲੇਟਫਾਰਮ ਕੁਝ ਹੱਥ-ਮਾਪਣ ਵੇਖਦੇ ਹਨ ਜੋ ਸਿਹਤ ਨੂੰ ਸੰਕੇਤ ਕਰਦੇ ਹਨ:
ਜਦੋਂ ਇਹ ਸੁਚਕ ਉਠਦੇ ਹਨ, ਆਮਤੌਰ 'ਤੇ ਇੱਕ ਹੀ ਸਮੱਸਿਆ ਨਹੀਂ ਹੁੰਦੀ—ਇਹ ਦੋਨੋਂ ਪਾਸਿਆਂ ਵਿੱਚ ਇੱਕ ਚੇਨ ਰੀਐਕਸ਼ਨ ਹੁੰਦੀ ਹੈ।
Uber-ਸਟਾਈਲ ਮਾਰਕੀਟਪਲੇਸ ਵਿੱਚ ਲਿਕਵਿਡਿਟੀ ਨੂੰ ਸਧਾਰਨ ਤੌਰ 'ਤੇ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ: ਜ਼ਿਆਦਾਤਰ ਸਮਿਆਂ ਵਿੱਚ ਮੰਗ ਲਈ ਨੇੜੇ ਕਾਫੀ ਸਪਲਾਈ ਹੋਵੇ। ਨਾ ਕਿ "ਸ਼ਹਿਰ ਵਿੱਚ ਕਈ ਡ੍ਰਾਈਵਰ" ਪਰ ਉਹ ਡ੍ਰਾਈਵਰ ਇੰਨੇ ਨੇੜੇ ਹੋਣ ਕਿ ਯਾਤਰੀ ਤੇਜ਼ ਅਤੇ ਭਰੋਸੇਯੋਗ ਮੇਚ ਲੈ ਸਕੇ।
ਜਦੋਂ ਲਿਕਵਿਡਿਟੀ ਘੱਟ ਹੁੰਦੀ ਹੈ, ਲੱਛਣ ਤੁਰੰਤ ਸਾਹਮਣੇ ਆਉਂਦੇ ਹਨ:
ਇਹ ਬੇਟੇਲ-ਇਕਾਈਆਂ ਵੱਖ-ਵੱਖ ਮੁਹਾਂ ਹਨ—ਇਹਨਾਂ ਸਭ ਨੂੰ ਇੱਕੋ ਘਾਟ ਬਣਾਉਂਦੀ ਹੈ: ਲੋਕੇਸ਼ਨ-ਅਧਾਰਤ ਉਪਲਬਧਤਾ ਦੀ ਘਾਟ।
ਇੱਕ ਸ਼ਹਿਰ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਡ੍ਰਾਈਵਰ ਹੋ ਕੇ ਵੀ ਅਨਭਵ "ਸੁੱਕਾ" ਰਹਿ ਸਕਦਾ ਹੈ ਜੇ ਉਹ ਫੈਲੇ ਹੋਏ ਹਨ। ਲਿਕਵਿਡਿਟੀ ਹਾਈਪਰ-ਲੋਕਲ ਹੈ: ਇਹ ਮਿੰਟ ਅਤੇ ਬਲਾਕ ਦੇ ਅਨੁਸਾਰ ਬਦਲਦੀ ਹੈ।
ਇੱਕ ਸਟੇਡੀਅਮ 10:17 ਵਜੇ ਨਿਕਲਣਾ 10:19 ਵਜੇ ਨੇੜੇ ਪੜੋਸ ਨਾਲੋਂ ਵੱਖਰਾ ਬਜ਼ਾਰ ਹੈ। ਇੱਕ ਭਿੱਜਾ ਚੌਕ ਸੂਕਾ ਚੌਕ ਤੋਂ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਛੋਟੀ ਰੋਡ ਕਲੋਜ਼ਰ ਵੀ ਇਹ ਦਰਸਾ ਸਕਦੀ ਹੈ ਕਿ ਸਪਲਾਈ ਕਿੱਥੇ ਜੁਮ੍ਹਦੀ ਹੈ ਅਤੇ ਕਿੱਥੇ ਗਾਇਬ।
ਇਸ ਲਈ ਡੈਂਸਿਟੀ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਹਰ ਇਕ ਜ਼ਿਆਦਾ ਮੀਲ ਯਾਤਰੀ ਅਤੇ ਡ੍ਰਾਈਵਰ ਵਿਚਕਾਰ ਉਡੀਕ, ਅਣਿਸ਼ਚਿਤਤਾ ਅਤੇ ਰੱਦ-ਕਿਰਿਆ ਦਾ ਮੌਕਾ ਵਧਾਉਂਦੀ ਹੈ।
ਜਦੋਂ ਯਾਤਰੀ ਭਰੋਸਾ ਕਰਦੇ ਹਨ ਕਿ "ਕਾਰ ਆ ਕੇ ਲੱਗੇਗੀ," ਉਹ ਘੱਟ ਸੋਚ-ਵਿਚਾਰ ਨਾਲ ਫ਼ਿਰ ਬੁੱਕ ਕਰਦੇ ਹਨ ਅਤੇ ਵੱਖ-ਵੱਖ ਸਮਿਆਂ 'ਤੇ ਵੀ। ਇਹ ਸਥਿਰ ਮੰਗ ਡ੍ਰਾਈਵਰਾਂ ਨੂੰ ਆਮਦਨੀ ਦਾ ਅੰਦਾਜ਼ਾ ਦੇਣ ਵਿੱਚ ਸਹਾਇਕ ਹੁੰਦੀ ਹੈ ਤਾਂ ਕਿ ਉਹ ਆਨਲਾਈਨ ਰਹਿਣ। ਹੋਰ ਲਗਾਤਾਰ ਸਪਲਾਈ ਫਿਰ ਭਰੋਸਾ ਵਧਾਉਂਦੀ ਹੈ।
ਲਿਕਵਿਡਿਟੀ ਸਿਰਫ਼ ਨਤੀਜਾ ਹੀ ਨਹੀਂ—ਇਹ ਦੋਹਾਂ ਪਾਸਿਆਂ ਨੂੰ ਵਰਤਣ ਲਈ ਪ੍ਰੇਰਿਤ ਕਰਨ ਵਾਲਾ ਸੰਕੇਤ ਹੈ।
Uber ਦੇ ਹਰੇਕ ਨਿੰਰਭ ਦਾ ਨਤੀਜਾ ਇੱਕ ਲਗਾਤਾਰ ਅੱਪਡੇਟ ਹੋ ਰਹੀ ਤਸਵੀਰ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦਾ ਹੈ: ਇੱਕ "ਰੀਅਲ-ਟਾਈਮ ਸਟੇਟ" ਜੋ ਗੰਦੇ ਸੜਕਾਂ ਨੂੰ ਉਹ ਇੰਪੁਟ ਦਿੰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ 'ਤੇ ਸਿਸਟਮ ਕਾਰਵਾਈ ਕਰ ਸਕਦਾ ਹੈ।
ਚਰਲੀ ਸੰਕੇਤਾਂ 'ਤੇ ਇਹ ਸਟੇਟ ਬਣੀ ਹੁੰਦੀ ਹੈ:
ਪ੍ਰਤੀਕਿਰਿਆ ਸਧਾਰਨ ਹੈ: ਕਿਸੇ ਖੇਤਰ ਵਿੱਚ ਬੇਨਤੀਆਂ ਵਧਦੀਆਂ ਹਨ ਅਤੇ ਸਿਸਟਮ ਜਵਾਬ ਦਿੰਦਾ ਹੈ।
ਪਰ ਸਭ ਤੋਂ ਕੀਮਤੀ ਕਦਮ ਪੇਸ਼ਗੋਈ ਹੈ—ਉਮੀਦ ਲਗਾਉਣਾ ਕਿ ਸਪਲਾਈ ਅਤੇ ਮੰਗ ਕਿੱਥੇ ਹੋਣਗੇ ਪਹਿਲਾਂ ਹੀ, ਤਾਂ ਜੋ ਉਹ ਬਹੁਤ ਦੂਰ ਨਾ ਖਿੱਚ ਜਾਣ। ਇਹ ਕਨਸਰਟ ਦੇ ختم ਹੋਣ, ਬਾਰਿਸ਼ ਜਾਂ ਸਵੇਰੇ ਕੰਮ 'ਤੇ ਆਮ ਮੁਹੱਈਆ ਦੇ ਅਨੁਕੂਲ ਹੋ ਸਕਦਾ ਹੈ। ਪੇਸ਼ਗੋਇਆਂ ਨਾਲ ਪਿਛਲੇ ਸਮੱਸਿਆ ਨੂੰ ਪਿੱਛੇ ਦੌੜਣ ਤੋਂ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ।
"ਰੀਅਲ-ਟਾਈਮ" ਲੇਬਲ ਦੇ ਬਾਵਜੂਦ, ਫੈਸਲੇ ਆਮ ਤੌਰ 'ਤੇ ਬੈਚਾਂ ਵਿੱਚ ਲਏ ਜਾਂਦੇ ਹਨ:
ਅਸਲੀ ਸੜਕਾਂ ਗੰਦੇ ਡੇਟਾ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ। GPS ਸ਼ਹਿਰੀ ਗਹਿਰਾਈਆਂ ਵਿੱਚ ਡ੍ਰਿਫਟ ਕਰ ਸਕਦਾ ਹੈ, ਅਪਡੇਟ ਦੇਰੀ ਨਾਲ ਆ ਸਕਦੇ ਹਨ, ਅਤੇ ਕੁਝ ਸਿਗਨਲ ਪੂਰੀ ਤਰ੍ਹਾਂ ਗੁੰਮ ਵੀ ਹੋ ਸਕਦੇ ਹਨ ਜਦੋਂ ਫੋਨ ਕੰਮ ਤੋਂ ਬਾਹਰ ਹੋ। ਡੇਟਾ ਪਰਤ ਦਾ ਇੱਕ ਵੱਡਾ ਹਿੱਸਾ ਇਹ ਪਛਾਣਨਾ ਅਤੇ ਠੀਕ ਕਰਨਾ ਹੈ ਤਾਂ ਜੋ ਬਾਅਦੀ ਫੈਸਲੇ ਭੂਤ-ਸਥਿਤੀਆਂ, ਬੁਜ਼ੁਰਗ ਸਥਿਤੀਆਂ ਜਾਂ ਗਲਤ ਸਪੀਡਾਂ 'ਤੇ ਆਧਾਰਿਤ ਨਾ ਹੋਣ।
ਜੇ ਤੁਸੀਂ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਇਹ ਸਿਗਨਲ ਬਾਅਦ ਵਿੱਚ ਕਿਵੇਂ ਪ੍ਰਭਾਵ ਪਾਉਂਦੇ ਹਨ, ਤਾਂ blog/dynamic-pricing-balancing-supply-and-demand ਦੇਖੋ।
ਡਾਇਨਾਮਿਕ ਪ੍ਰਾਇਸਿੰਗ (ਅਕਸਰ ਸਰਜ ਪ੍ਰਾਇਸਿੰਗ) ਨੂੰ ਇੱਕ ਬੈਲੰਸਿੰਗ ਸਾਧਨ ਵਜੋਂ ਸਮਝਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਮੁੱਖ ਤੌਰ 'ਤੇ "ਹੋਰ ਚਾਰਜ ਕਰਨ ਦਾ ਤਰੀਕਾ" ਨਹੀਂ ਹੈ; ਇਹ ਇੱਕ ਕੰਟਰੋਲ ਨੋਬ ਹੈ ਜੋ ਪਲੇਟਫਾਰਮ ਬਦਲਦਾ ਹੈ ਜਦੋਂ ਮਾਰਕੀਟਪਲੇਸ ਅਸਮਤੁਲਨ ਵਿੱਚ ਚੱਲ ਜਾਂਦਾ ਹੈ।
ਰਾਈਡ ਮਾਰਕੀਟਪਲੇਸ ਦੀ ਇੱਕ ਸਧਾਰਨ ਸਮੱਸਿਆ ਹੈ: ਲੋਕ ਬੁਰਸਟ ਵਿੱਚ ਟਰਿੱਪ ਮੰਗਦੇ ਹਨ, ਜਦਕਿ ਉਪਲਬਧ ਡ੍ਰਾਈਵਰ ਹਰ ਸਮੇਂ ਬਰਾਬਰ ਨਹੀਂ ਹੁੰਦੇ। ਸਿਸਟਮ ਦਾ ਲਕੜੀ ਇਹ ਹੈ ਕਿ ਅਤਿ-ਮੰਗ ਨੂੰ ਘਟਾਵੇ ਅਤੇ ਉਚਿਤ ਖੇਤਰਾਂ ਵਿੱਚ ਪੂਰਤੀ ਨੂੰ ਆਕਰਸ਼ਿਤ ਜਾਂ ਬਚਾਏ।
ਜਦੋਂ ਕੀਮਤ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਦੀ ਹੈ, ਪਲੇਟਫਾਰਮ ਇੱਕੋ ਸਮੇਂ ਦੋ ਫੈਸਲੇ ਪ੍ਰਭਾਵਿਤ ਕਰ ਰਹੀ ਹੁੰਦੀ ਹੈ:
ਇਸ ਤਰ੍ਹਾਂ ਸੋਚੋ:
ਇਹ ਮਿੰਟ-ਦਰ-ਮਿੰਟ ਕੰਮ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਹਾਲਾਤ ਹਰ ਮਿੰਟ ਬਦਲਦੇ ਹਨ: ਕਾਨਸਰਟ ਖਤਮ ਹੁੰਦਾ ਹੈ, ਬਾਰਿਸ਼ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਟਰੇਨਡਿਲੇ ਹੋ ਜਾਂਦੇ ਹਨ, ਇਕ ਪੜੋਸ ਅਚਾਨਕ ਖਾਲੀ ਹੋ ਜਾਂਦਾ ਹੈ।
ਕਿਉਂਕਿ ਕੀਮਤ ਲੋਕਾਂ 'ਤੇ ਸਿੱਧਾ ਅਸਰ ਪਾਂਦੀ ਹੈ, ਡਾਇਨਾਮਿਕ ਪ੍ਰਾਇਸਿੰਗ ਆਮ ਤੌਰ 'ਤੇ ਗਾਰਡਰੇਲਸ ਦੀ ਲੋੜ ਰੱਖਦੀ ਹੈ। ਆਦਰਸ਼ ਤੌਰ 'ਤੇ ਇਨ੍ਹਾਂ ਵਿੱਚ ਸ਼ਾਮਿਲ ਹੋ ਸਕਦੇ ਹਨ:
ਅਹਮ ਗੱਲ ਇਹ ਹੈ ਕਿ ਡਾਇਨਾਮਿਕ ਪ੍ਰਾਇਸਿੰਗ ਇੱਕ ਵਿਹਾਰਕ ਸੰਕੇਤ ਹੈ। ਇਹ ਮਾਰਕੀਟਪਲੇਸ ਨੂੰ ਵਰਤਣਯੋਗ ਰੱਖਣ ਲਈ ਇਕ ਤਰੀਕਾ ਹੈ—ਇਹ ਪਿਕਅਪ ਸੰਭਵ ਬਣਾਂਦੀ ਹੈ ਅਤੇ ਉਡੀਕ ਸਮੇਂ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ ਜਦੋਂ ਸ਼ਹਿਰ ਦੀ ਪੂਰਤੀ ਅਤੇ ਸਪਲਾਈ ਛੇਤੀ ਮਿਲਣਾ ਬੰਦ ਹੋ ਜਾਂਦੇ ਹਨ।
ਰਾਈਡ-ਹੇਲਿੰਗ ਪਲੇਟਫਾਰਮ 'ਤੇ ਪ੍ਰਾਇਸਿੰਗ ਸਿਰਫ਼ "ਬਿਜੀ ਹੋਣ 'ਤੇ ਉੱਚ, ਸੁੰਨ੍ਹੇ ਸਮੇਂ 'ਤੇ ਘੱਟ" ਨਹੀਂ ਹੁੰਦੀ। ਅਲਗੋਰਿਦਮ ਦਾ ਮਕਸਦ ਮਾਰਕੀਟਪਲੇਸ ਚਲਾਉਣਾ ਹੈ: ਕਾਫੀ ਯਾਤਰੀ درخواست ਕਰਨ, ਕਾਫੀ ਡ੍ਰਾਈਵਰ ਉਨ੍ਹਾਂ ਨੂੰ ਕਬੂਲ ਕਰਨ, ਅਤੇ ਯਾਤਰੀਆਂ ਨੂੰ ਅਨੁਮਾਨਿਤ ਉਡੀਕ ਸਮੇਂ ਨਾਲ ਯਾਤਰਾ ਮਿਲਣਾ।
ਸਹੀਅਤ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਗਲਤੀਆਂ ਦੇ ਖਰਚੇ ਅਸਮੀਤ ਹੋ ਸਕਦੇ ਹਨ। ਜੇ ਸਿਸਟਮ ਜ਼ਿਆਦਾ ਕੀਮਤ ਲਗਾ ਦੇਵੇ ਤਾਂ ਯਾਤਰੀ ਪਿੱਛੇ ਹਟ ਜਾਂਦੇ ਹਨ ਜਾਂ ਯਾਤ ਨੂੰ ਟਾਲ਼ਦੇ ਹਨ, ਅਤੇ ਪਲੇਟਫਾਰਮ ਨੂੰ ਮੋਹ ਲੱਗਣ ਦੀ ਛਾਪ ਪੈ ਸਕਦੀ ਹੈ। ਜੇ ਇਹ ਇੱਕ ਸਪਾਈਕ ਦੌਰਾਨ ਘੱਟ ਕੀਮਤ ਰੱਖਦਾ ਹੈ, ਤਾਂ ਬੇਨਤੀਆਂ ਡ੍ਰਾਈਵਰਾਂ ਦੇ ਸਮਰਥਨ ਤੋਂ ਤੇਜ਼ ਦਿਖਾਈ ਦੇ ਸਕਦੀਆਂ ਹਨ—ETA ਵੱਧ ਜਾਂਦੇ ਹਨ, ਰੱਦ-ਕਿਰਿਆਵਾਂ ਵਧਦੀਆਂ ਹਨ, ਅਤੇ ਡ੍ਰਾਈਵਰ ਨਿਰਾਸ਼ ਹੋ ਸਕਦੇ ਹਨ। ਦੋਹਾਂ ਹਲਾਤਾਂ ਵਿੱਚ ਭਰੋਸਾ ਘਟਦਾ ਹੈ।
ਅਧਿਕਤਰ ਪ੍ਰਾਇਸਿੰਗ ਪ੍ਰਣਾਲੀਆਂ ਨਜ਼ਦੀਕੀ ਹਾਲਾਤਾਂ ਦੀ ਅਨੁਮਾਨ ਲਗਾਉਣ ਲਈ ਕਈ ਸਿਗਨਲ ਮਿਲਾਉਂਦੀਆਂ ਹਨ:
ਮਕਸਦ ਸਹੀ ਭਵਿੱਖ ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰਨ ਤੋਂ ਘੱਟ ਹੈ—ਅਗਲੇ ਪਲ ਵਿੱਚ ਵਿਹਾਰ ਨੂੰ ਢਾਲਣਾ ਹੈ, ਕਾਫੀ ਡ੍ਰਾਈਵਰਾਂ ਨੂੰ ਬਿਜੀ ਖੇਤਰ ਵੱਲ ਖਿੱਚਣਾ ਅਤੇ ਉਹ ਬੇਨਤੀਆਂ ਜੋ ਸੇਵਾ ਨਹੀਂ ਮਿਲ ਸਕਦੀ, ਉਨ੍ਹਾਂ ਨੂੰ ਹਟਾਉਣਾ।
ਚਾਹੇ ਮੰਗ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲੇ, ਕੀਮਤ ਬਿਨਾ ਕੰਟਰੋਲ ਦੇ ਜ਼ੋਰ ਨਾਲ ਨਹੀਂ ਘੁਮਣੀ ਚਾਹੀਦੀ। ਸਮੂਥਿੰਗ ਤਕਨੀਕਾਂ (ਧੀਰੇ-ਧੀਰੇ ਐਡਜਸਟਮੈਂਟ, ਕੈਪ, ਸਮੇਂ ਦੀ ਖਿੜਕੀ ਆਧਾਰਿਤ ਅਵਰੇਜਿੰਗ) ਛੋਟੇ ਡੇਟਾ ਬਦਲਾਵਾਂ ਕਾਰਨਾਂ ਅਚਾਨਕ ਝੱਟਕੇ ਰੋਕਦੀਆਂ ਹਨ, ਅਤੇ ਫਿਰ ਵੀ ਵਾਸਤਵਿਕ, ਇਵੈਂਟ-ਚਲਤ ਸਪਾਈਕਾਂ ਲਈ ਤੇਜ਼ ਜਵਾਬ ਦੇ ਸਕਦੀਆਂ ਹਨ।
ਕਿਉਂਕਿ ਯਾਤਰੀ ਅਤੇ ਡ੍ਰਾਈਵਰ ਦੇ ਵਿਹਾਰ ਸੰਵੇਦਨਸ਼ੀਲ ਹੁੰਦੇ ਹਨ, ਪਲੇਟਫਾਰਮ ਆਮ ਤੌਰ 'ਤੇ ਸਮਰੱਥ A/B ਟੈਸਟਿੰਗ ਵਰਗੇ ਸੋਧਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ ਤਾਂ ਕਿ ਨਿਰੀਖਣਾਂ—ਕਨਵਰਜ਼ਨ, ਕਬੂਲ, ਰੱਦ-ਕਿਰਿਆਵਾਂ, ਉਡੀਕ—ਬਿਨਾਂ ਕਿਸੇ ਇਕ "ਪਰਫੈਕਟ" ਕੀਮਤ ਧਾਰਨਾ ਦੇ ਸੁਧਾਰ ਕੀਤੇ ਜਾ ਸਕਣ।
ਡਿਸਪੈਚ ਉਹ ਸਮਾਂ ਹੈ ਜਦੋਂ ਮਾਰਕੀਟਪਲੇਸ ਆਗੇ ਨਿਰੀਤ ਹੁੰਦਾ ਹੈ: ਪ੍ਰਣਾਲੀ ਫੈਸਲਾ ਕਰਦੀ ਹੈ ਕਿ ਕੌਣ ਡ੍ਰਾਈਵਰ ਕਿਸ ਯਾਤਰੀ ਨੂੰ ਲੈਵੇਗਾ, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਕੀ ਸਭ ਤੋਂ ਵਧੀਆ ਕਾਰਵਾਈ ਹੋਵੇਗੀ।
ਕਿਸੇ ਵੀ ਲਹਜ਼ੇ 'ਚ ਨੇੜੇ ਕਈ ਸੰਭਵ ਜੋੜੇ ਹੁੰਦੇ ਹਨ। ਡਿਸਪੈਚ ਅਤੇ ਮੇਚਿੰਗ ਉਹ ਪ੍ਰਕਿਰਿਆ ਹੈ ਜੋ ਇੱਕ ਜੋੜ ਬਣਾਉਂਦੀ ਹੈ—ਇਹ ਜਾਣ ਕੇ ਕਿ ਇਹ ਚੋਣ ਅਗਲੇ ਕੁਝ ਮਿੰਟਾਂ 'ਚ ਸੰਭਾਵਨਾਵਾਂ ਨੂੰ ਬਦਲ ਦੇਵੇਗੀ।
ਇਹ ਸਿਰਫ਼ "ਸਭ ਤੋਂ ਨੇੜੇ ਡ੍ਰਾਈਵਰ ਨੂੰ ਰਿਕਵੇਸਟ" ਨਹੀਂ ਹੁੰਦਾ। ਇੱਕ ਪਲੇਟਫਾਰਮ ਸੋਚ ਸਕਦਾ ਹੈ ਕਿ ਕੌਣ ਸਭ ਤੋਂ ਤੇਜ਼ ਪਹੁੰਚ ਸਕਦਾ ਹੈ, ਕੌਣ ਕਬੂਲ ਕਰਨ ਦੀ ਸੰਭਾਵਨਾ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਇਹ ਅਸਾਈਨਮੈਂਟ ਖੇਤਰ ਵਿਚ ਕਿਸ ਤਰ੍ਹਾਂ ਪ੍ਰਭਾਵ ਪਾਵੇਗਾ। ਜਦੋਂ ਪੂਲਿੰਗ ਉਪਲਬਧ ਹੋਵੇ, ਇਹ ਵਿਚਾਰ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਦੋ ਯਾਤਰੀ ਇਕੋ ਵਾਹਨ ਸਾਂਝੇ ਕਰ ਸਕਦੇ ਹਨ ਬਿਨਾਂ ਵਾਅਦੇ ਕੀਤੇ ਪਿਕਅਪ ਅਤੇ ਡ੍ਰੌਪ-ਆਫ ਸਮਿਆਂ ਨੂੰ ਭੰਗ ਕੀਤੇ।
ਆਮ ਮਕਸਦ ਪਿਕਅਪ ਟਾਈਮ ਘਟਾਨਾ ਹੈ, ਸਗੋਂ ਓਵਰਆਲ ਸਿਸਟਮ ਦੀ ਸਿਹਤ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਣਾ ਵੀ। “ਸਿਹਤਮੰਦ” ਵਿੱਚ ਸ਼ਾਮਿਲ ਹਨ ਯਾਤਰੀ ਅਭਿਜ਼ੋਗ (ਛੋਟੀ ਉਡੀਕ, ਭਰੋਸੇਯੋਗ ETA), ਡ੍ਰਾਈਵਰ ਅਨੁਭਵ (ਲਗਾਤਾਰ ਕਮਾਈ, ਮਨੀ-ਡੈੱਡਹੈਡਿੰਗ), ਅਤੇ ਨਿਆਯ (ਕੋਈ ਖੇਤਰ ਜਾਂ ਸਮੂਹ ਲਗਾਤਾਰ ਖਰਾਬ ਸੇਵਾ ਨਾ ਪਾਏ)।
ਡਿਸਪੈਚ ਫੈਸਲੇ ਹਕੀਕਤ-ਅਧਾਰਤ ਨਿਯਮਾਂ ਦੇ ਅਧੀਨ ਹੁੰਦੇ ਹਨ:
ਹਰ ਇੱਕ ਮੇਚ ਸਪਲਾਈ ਨੂੰ ਖਿਸਕਾਉਂਦਾ ਹੈ। ਇੱਕ ਡ੍ਰਾਈਵਰ ਨੂੰ 6 ਮਿੰਟ ਉੱਤਰ ਵੱਲ ਭੇਜਨਾ ਇੱਕ ਯਾਤਰੀ ਦੀ ਉਡੀਕ ਵਧਾ ਸਕਦਾ ਹੈ—ਪਰ ਇਹ ਦੱਖਣ ਤੋਂ ਸਪਲਾਈ ਨੂੰ ਹਟਾ ਦੇਂਦਾ ਹੈ, ਭਵਿੱਖੀ ETA ਵਧਾਉਂਦਾ ਹੈ ਅਤੇ ਹੋਰ ਰੀਪੋਜ਼ੀਸ਼ਨਿੰਗ ਨੂੰ ਭੜਕਾ ਸਕਦਾ ਹੈ। ਇਸ ਲਈ ਡਿਸਪੈਚ ਇੱਕ ਲਗਾਤਾਰ ਕੋਆਰਡੀਨੇਸ਼ਨ ਮੁੱਦਾ ਹੈ: ਹਜ਼ਾਰਾਂ ਛੋਟੇ ਫੈਸਲੇ ਜੋ ਮਿਲ ਕੇ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ ਕਿ ਕਾਰਾਂ ਕਿੱਥੇ ਹੋਣਗੀਆਂ, ਯਾਤਰੀ ਕੀ ਦੇਖਣਗੇ, ਅਤੇ ਮਾਰਕੀਟਪਲੇਸ ਕਿਵੇਂ ਲਿਕਵਿਡ ਰਹੇਗੀ।
Uber ਦਾ ਮੁੱਖ ਵਾਅਦਾ ਸਿਰਫ਼ "ਕਾਰ ਆਵੇਗੀ" ਨਹੀਂ—ਇਹ ਹੈ ਕਿੰਨੀ ਜਲਦੀ, ਕਿੰਨੀ ਪੇਸ਼ਗੋਇਤ ਅਤੇ ਯਾਤਰਾ ਕਿੰਨੀ ਸਹਿਜ਼ੀ ਨਾਲ ਲੱਗੇਗੀ। ਲੌਜਿਸਟਿਕ ਕੋਆਰਡੀਨੇਸ਼ਨ ਉਹ ਪਰਤ ਹੈ ਜੋ ਇਸ ਵਾਅਦੇ ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀ ਹੈ, ਜਦ ਕਿ ਸੜਕਾਂ, ਮੌਸਮ, ਇਵੈਂਟ ਅਤੇ ਮਨੁੱਖੀ ਚੋਣਾਂ ਲਗਾਤਾਰ ਬਦਲ ਰਹੀਆਂ ਹੁੰਦੀਆਂ ਹਨ।
ETA ਇੱਕ ਉਤਪਾਦ ਦਾ ਹਿੱਸਾ ਹੈ: ਯਾਤਰੀ ਉਸ ਦੇ ਆਧਾਰ 'ਤੇ ਬੁੱਕ ਕਰਨ ਜਾਂ ਰੱਦ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਡ੍ਰਾਈਵਰ ਇਸ ਦੇ ਆਧਾਰ 'ਤੇ ਸੋਚਦਾ ਹੈ ਕਿ ਟ੍ਰਿਪ ਲਾਭਕਾਰੀ ਹੈ ਜਾਂ ਨਹੀਂ। ETA ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਲਈ ਸਿਸਟਮ ਮੈਪ ਡੇਟਾ ਨੂੰ ਰੀਅਲ-ਟਾਈਮ ਸਿਗਨਲਾਂ ਨਾਲ ਜੋੜਦਾ—ਸਪਸ਼ਟ ਸੜਕ ਸੈਗਮੈਂਟਾਂ 'ਤੇ ਹਾਲੀਆ ਟ੍ਰੈਫਿਕ ਸਪੀਡ, ਸਮੇਂ ਦੇ ਅਨੁਸਾਰ ਆਮ ਸਲੋਡਾਊਨ, ਅਤੇ ਜੋ ਕੁਝ ਹੁਣ ਹੋ ਰਿਹਾ ਹੈ (ਕੰਸਟ੍ਰਕਸ਼ਨ, ਦੁਰਘਟਨਾ, ਜਾਂ ਸਟੇਡੀਅਮ ਖੁਲਣਾ)।
ਰੂਟਿੰਗ ਇਸ ਤੋਂ ਪੈਦਾ ਹੁੰਦੀ ਹੈ: ਇਹ ਸਿਰਫ਼ "ਸਰਵੋਤਮ ਦੂਰੀ" ਨਹੀਂ, ਪਰ ਅਕਸਰ "ਤੇਜ਼ ਦਾ ਅਨੁਮਾਨਿਤ ਸਮਾਂ" ਹੁੰਦੀ ਹੈ, ਜੋ ਹਾਲਾਤ ਬਦਲਣ 'ਤੇ ਅਪਡੇਟ ਹੁੰਦੀ ਰਹਿੰਦੀ ਹੈ। ਜਦ ETA ਘਟਦੀ ਜਾਂ ਵਧਦੀ ਹੈ, ਪਲੇਟਫਾਰਮ ਪਿਕਅਪ ਪੁਆਇੰਟ, ਬਦਲੀਆਂ ਸਲਾਹਾਂ, ਜਾਂ ਦੋਹਾਂ ਪਾਸਿਆਂ ਦੀ ਉਮੀਦਾਂ ਨੂੰ ਅਪਡੇਟ ਕਰ ਸਕਦੀ ਹੈ।
ਅੱਛੀ ਰੂਟਿੰਗ ਦੇ ਬਾਵਜੂਦ, ਸਪਲਾਈ ਨੂੰ ਫਿਰ ਵੀ ਮੰਗ ਦੇ ਨੇੜੇ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਰੀਪੋਜ਼ੀਸ਼ਨਿੰਗ ਸਥਿਤੀਵਾਰ ਡ੍ਰਾਈਵਰਾਂ ਨੂੰ ਉਸ ਖੇਤਰ ਵੱਲ ਜਾਣ ਦੀ ਚੋਣ ਹੈ ਜਿੱਥੇ ਜਲਦੀ ਬੇਨਤੀਆਂ ਹੋਣ ਦੀ ਉਮੀਦ ਹੈ। ਪਲੇਟਫਾਰਮ ਇਸਨੂੰ ਸਿਰਫ਼ ਉੱਚ ਫੇਅਰਾਂ ਰਾਹੀਂ ਨਹੀਂ, ਬਲਕਿ ਹੋਰ ਤਰੀਕਿਆਂ ਨਾਲ ਵੀ ਉਤਸ਼ਾਹਤ ਕਰਦਾ ਹੈ: ਬਜ਼ੀ ਜ਼ੋਨਾਂ ਵਾਲੇ ਹੀਟਮੈਪ, "ਡਾਊਨਟਾਊਨ ਵੱਲ ਜਾਓ" ਵਰਗੀਆਂ ਸਲਾਹਾਂ, ਏਅਰਪੋਰਟ/ਵੇਨਿਊ ਕਿਊ ਸਿਸਟਮ, ਅਤੇ ਨਿਯਮ ਜੋ ਨਿਰਧਾਰਤ ਇਲਾਕਿਆਂ 'ਚ ਰੁਕਣ ਲਈ ਇਨਾਮ ਦਿੰਦੇ ਹਨ।
ਕੋਆਰਡੀਨੇਸ਼ਨ ਦਾ ਇੱਕ ਫੀਡਬੈਕ ਮੁੱਦਾ ਵੀ ਹੈ: ਜਦ ਬਹੁਤ ਸਾਰੇ ਡ੍ਰਾਈਵਰ ਇੱਕੋ ਸਿਗਨਲ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ, ਉਹ ਟ੍ਰੈਫਿਕ ਵਿੱਚ ਵਾਧਾ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਪਿਕਅਪ ਭਰੋਸੇਯੋਗਤਾ ਘਟ ਸਕਦੀ ਹੈ। ਪਲੇਟਫਾਰਮ ਸ਼ਹਿਰ ਨੂੰ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਦਾ ਹੈ (ਟ੍ਰੈਫਿਕ ETA ਘਟਾਉਂਦਾ ਹੈ), ਅਤੇ ਸ਼ਹਿਰ ਵਾਪਸ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਦਾ ਹੈ (ਡ੍ਰਾਈਵਰ ਦੀ ਹਿਲਚਲ ਟ੍ਰੈਫਿਕ ਬਦਲ ਦਿੰਦੀ ਹੈ)। ਇਹ ਦੋ-ਤਰੀਫਾ ਲੂਪ ਹੈ ਜਿਸ ਕਰਕੇ ਰੂਟਿੰਗ ਅਤੇ ਰੀਪੋਜ਼ੀਸ਼ਨਿੰਗ ਸੰਕੇਤ ਲਗਾਤਾਰ ਅਨੁਕੂਲ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ—ਨਾ ਕਿ ਸਿਰਫ਼ ਮੰਗ ਦੇ ਪਿੱਛੇ ਭੱਜਣ ਲਈ, ਪਰ ਨਵੇਂ ਬੋਟਲਨੇਕ ਬਣਾਉਣ ਤੋਂ ਬਚਣ ਲਈ।
Uber ਸਿਰਫ਼ ਇੱਕ ਵਾਰੀ ਯਾਤਰੀ ਅਤੇ ਡ੍ਰਾਈਵਰ ਨੂੰ ਮੇਚ ਨਹੀਂ ਕਰਦਾ—ਇਹ ਲਗਾਤਾਰ ਵਿਹਾਰ ਨੂੰ ਸੰਚਾਲਿਤ ਕਰਦਾ ਹੈ। ਛੋਟੀ ਸੁਧਾਰਾਂ (ਜਾਂ ਨਾਕਾਮੀਆਂ) ਦਾ ਵਿਆਪਕ ਪ੍ਰਭਾਵ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਹਰ ਇੱਕ ਯਾਤਰਾ ਲੋਕਾਂ ਦੇ ਅਗਲੇ ਕਦਮਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ।
ਜਦੋਂ ਪਿਕਅਪ ਸਮਾਂ ਛੋਟੇ ਅਤੇ ਕੀਮਤ ਪੇਸ਼ਗੋਈਯੋਗ ਹੁੰਦੀ ਹੈ, ਯਾਤਰੀ ਵੱਧ ਬੁੱਕ ਕਰਦੇ ਹਨ। ਇਸ ਸਥਿਰ ਮੰਗ ਨਾਲ ਡ੍ਰਾਈਵਰਾਂ ਲਈ ਕਮਾਈ ਅਨੁਮਾਨਿਤ ਹੋ ਜਾਂਦੀ ਹੈ: ਉਹ ਜ਼ਿਆਦਾ ਹੀ ਆਨਲਾਈਨ ਰਹਿੰਦੇ ਹਨ ਅਤੇ ਘੱਟ ਸਮਾਂ ਬੇਕਾਰ ਬਿਤਾਉਂਦੇ ਹਨ।
ਸਹੀ ਸਪਲਾਈ ਫਿਰ ETA ਘਟਾਉਂਦੀ ਅਤੇ ਰੱਦ-ਕਿਰਿਆਵਾਂ ਘਟਾਉਂਦੀ ਹੈ, ਜੋ ਯਾਤਰੀ ਅਨੁਭਵ ਨੂੰ ਫਿਰ ਸੁਧਾਰਦਾ ਹੈ। ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ: ਚੰਗੀ ਸੇਵਾ → ਵੱਧ ਯਾਤਰੀ → ਵੱਧ ਡ੍ਰਾਈਵਰ → ਚੰਗੀ ਸੇਵਾ। ਇਹੀ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਇੱਕ ਸ਼ਹਿਰ ਸਿਹਤਮੰਦ ਹਾਲਤ ਵਿੱਚ "ਸਨੈਪ" ਹੋ ਸਕਦਾ ਹੈ ਜਿੱਥੇ ਮਾਰਕੀਟਪਲੇਸ ਬੇਬਾਕ ਲੱਗਦਾ ਹੈ।
ਉਹੀ ਸੰਯੋਜਨਾ ਮਾੜੇ ਦਿਸ਼ਾ ਵਿੱਚ ਵੀ ਚੱਲ ਸਕਦੀ ਹੈ। ਜੇ ਯਾਤਰੀਆਂ ਨੂੰ ਲਗਾਤਾਰ ਰੱਦ-ਕਿਰਿਆਵਾਂ ਜਾਂ ਲੰਮੇ ਉਡੀਕਾਂ ਮਿਲਦੀਆਂ ਹਨ, ਉਹ ਐਪ 'ਤੇ ਭਰੋਸਾ ਘਟਾ ਦੇਂਦੇ ਹਨ ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਯਾਤਰਾਵਾਂ ਲਈ ਇਹ ਐਪ ਵਰਤਣਾ ਘੱਟ ਕਰ ਦਿੰਦੇ ਹਨ।
ਕਮ ਰਿਕਵੇਸਟ ਵਾਲੀ ਹਾਲਤ ਡ੍ਰਾਈਵਰਾਂ ਦੀ ਆਮਦਨੀ ਦੇ ਅਣਿਸ਼ਚਿਤ ਕਰ ਦਿੰਦੀ ਹੈ, ਇਸ ਲਈ ਕੁਝ ਡ੍ਰਾਈਵਰ ਆਨਲਾਈਨ ਤੋਂ ਲੌਗ ਆਫ਼ ਕਰ ਜਾਂਦੇ ਹਨ ਜਾਂ ਬਿਜੀ ਖੇਤਰ ਵੱਲ ਦੂਰ ਹੋ ਜਾਂਦੇ ਹਨ। ਇਹ ਘਟਾਓ ETA ਹੋਰ ਬੁਰਾ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਰੱਦ-ਕਿਰਿਆਵਾਂ ਹੋਰ ਵਧਦੀਆਂ ਹਨ—ਰੱਦ-ਕਿਰਿਆਵਾਂ → ਭਰੋਸਾ ਘਟਣਾ → ਘੱਟ ਰਿਕਵੇਸਟ → ਘੱਟ ਲਿਕਵਿਡਿਟੀ।
ਕੁਝ ਲਹਜ਼ਿਆਂ ਦੀ ਬੇਮਿਸਾਲ ਸੇਵਾ ਮਾਇਨੇ ਨਹੀਂ ਰੱਖਦੀ ਜੇ ਆਮ ਤਉਰ 'ਤੇ ਅਨੁਭਵ ਅਸਥਿਰ ਹੋ। ਲੋਕ ਉਸ ਅਨੁਭਵ ਦੇ ਆਧਾਰ 'ਤੇ ਯੋਜਨਾ ਬਣਾਉਂਦੇ ਹਨ ਜੋ ਉਹ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹਨ। ਲਗਾਤਾਰ ETA ਅਤੇ ਘੱਟ "ਸ਼ਾਇਦ" ਨਤੀਜੇ (ਜਿਵੇਂ ਆਖਰੀ ਸਮੇਂ ਰੱਦ ਹੋਣਾ) ਆਦਤ ਬਣਾਉਂਦੇ ਹਨ, ਅਤੇ ਆਦਤ ਹੀ ਦੋਨੋਂ ਪਾਸਿਆਂ ਨੂੰ ਵਾਪਸ ਲਿਆਉਂਦੀ ਹੈ।
ਕੁਝ ਇਲਾਕੇ ਇੱਕ ਲੋਕਲ ਨਿ◌ਮੇਨਾ ਵਿੱਚ ਫਸ ਜਾਂਦੇ ਹਨ: ਘੱਟ ਸਪਲਾਈ → ਲੰਮੇ ਉਡੀਕ → ਯਾਤਰੀ ਬੁੱਕ ਕਰਨਾ ਘੱਟ ਕਰ ਦਿੰਦੇ ਹਨ → ਖੇਤਰ ਡ੍ਰਾਈਵਰਾਂ ਲਈ ਘੱਟ ਆਕਰਸ਼ਕ ਬਣ ਜਾਂਦਾ ਹੈ। ਬਾਹਰੀ ਧੱਕੇ ਦੇ ਬਿਨਾ—ਟਾਰਗੇਟਡ ਇਨਸੈਂਟਿਵ, ਸਮਾਰਟ ਰੀਪੋਜ਼ੀਸ਼ਨ, ਜਾਂ ਕੀਮਤ ਨੁੱਡ—ਇਹ ਪੜੋਸ ਕਾਫੀ ਸਮੇਂ ਲਈ ਘੱਟ-ਲਿਕਵਿਡ ਰਹਿ ਸਕਦੇ ਹਨ ਭਾਵੇਂ ਨੇੜੇ ਖੇਤਰ ਫਲੇਸ਼ੀ ਹੋ ਰਹੇ ਹੋਣ।
ਅਕਸਰ ਮਾਰਕੀਟਪਲੇਸ ਅਣੁਮਿਤੀਯੋਗ ਤਰੀਕੇ ਨਾਲ ਵਰਤਦਾ ਹੈ: ਮੰਗ ਉੱਪਰ-ਥੱਲੇ ਹੁੰਦੀ ਹੈ, ਡ੍ਰਾਈਵਰ ਬਦਲਦੇ ਹਨ, ਅਤੇ ETA ਇੱਕ ਜਾਣੀ-ਪਛਾਣੀ ਸੀਮਿਤ ਰੇਂਜ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ। "ਏਜ ਕੇਸ" ਉਹ ਮੋਮੈਂਟ ਹਨ ਜਦੋਂ ਇਹ ਪੈਟਰਨ ਟੁੱਟ ਜਾਂਦੇ ਹਨ—ਅਕਸਰ ਅਚਾਨਕ—ਅਤੇ ਸਿਸਟਮ ਨੂੰ ਗੰਦੇ, ਅਧੂਰੇ ਇਨਪੁਟਾਂ ਨਾਲ ਫੈਸਲੇ ਕਰਨੇ ਪੈਂਦੇ ਹਨ।
ਇਵੈਂਟ ਸਪਾਈਕ (ਕਾਨਸਰਟ, ਸਟੇਡੀਅਮ), ਮੌਸਮ ਦੇ ਜਟਿਲ ਝਟਕੇ, ਅਤੇ ਵੱਡੇ ਰੋਡ ਕਲੋਜ਼ਰ ਸਿੰਕ੍ਰਨਾਈਜ਼ਡ ਮੰਗ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ ਨਾਲ ਹੀ ਪਿਕਅਪ ਅਤੇ ਡ੍ਰੌਪ-ਆਫ ਨੂੰ ਧੀਮਾ ਕਰਦੇ ਹਨ। ਐਪ ਆਊਟੇਜ ਜਾਂ ਭੁਗਤਾਨ ਫੇਲਿਅਰ ਵੱਖ ਕਿਸਮ ਦੇ ਹਨ: ਉਹ ਸਿਰਫ਼ ਮੰਗ ਨੂੰ ਨਹੀਂ ਬਦਲਦੇ—ਉਹ ਉਹ ਫੀਡਬੈਕ ਚੈਨਲਾਂ ਨੂੰ ਹੀ ਰੁਕਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਰਾਹੀਂ ਪਲੇਟਫਾਰਮ ਸ਼ਹਿਰ ਨੂੰ "ਦੇਖਦੀ" ਹੈ। ਛੋਟੀਆਂ ਸਮੱਸਿਆਵਾਂ (ਡੈਂਸਟੀ ਡਾਊਨਟਾਊਨ GPS ਡ੍ਰਿਫਟ, ਸਬਵੇ ਡੀਲੇ) ਨੂੰ ਵੀ ਬਹੁਤੋਂ ਵਰਤੋਂਕਾਰ ਇੱਕੱਠੇ ਮਹਿਸੂਸ ਕਰਨ 'ਤੇ ਵੱਡਾ ਪ੍ਰਭਾਵ ਪੈ ਸਕਦਾ ਹੈ।
ਜਦੋਂ ਸਿਗਨਲ ਦੇਰੀ ਵਾਲੇ ਜਾਂ ਅਧੂਰੇ ਹੁੰਦੇ ਹਨ, ਕੋਆਰਡੀਨੇਸ਼ਨ ਸਭ ਤੋਂ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦੀ ਹੈ। ਡ੍ਰਾਈਵਰ ਜਾਣਬੂਝ ਕੇ ਮੋਟਰੇ ਹੋ ਸਕਦੇ ਹਨ, ਬਹੁਤ ਸਾਰੇ ਡ੍ਰਾਈਵਰ ਮਿਡ-ਟ੍ਰਿਪ ਫਸੇ ਹੋ ਸਕਦੇ ਹਨ, ਜਾਂ ਟ੍ਰਿਪ ਕਬੂਲ ਕਰਨ ਵਿੱਚ ਸੰਕੋਚ ਹੋ ਸਕਦਾ ਹੈ। ਇਸੇ ਤਰ੍ਹਾਂ, ਇੱਕ ਬੇਨਤੀ ਸਪਾਈਕ ਐਸਾਰੇ ਤੌਰ 'ਤੇ ਆ ਸਕਦੀ ਹੈ ਕਿ ਸਿਸਟਮ ਸਪਲਾਈ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਕਾਫੀ ਤੇਜ਼ ਨਹੀਂ। ਇਸ ਲਈ ਨਜ਼ਦੀਕੀ ਪੇਸ਼ਗੋਈਆਂ ਅਕਸਰ ਅਤਿਕਵਿੱਚ ਪੇਸ਼-ਮੁੱਦਾਂ ਨੂੰ ਓਵਰ-ਸ਼ੂਟ ਜਾਂ ਅੰਡਰ-ਸ਼ੂਟ ਕਰ ਸਕਦੀਆਂ ਹਨ।
ਪਲੇਟਫਾਰਮ ਆਮ ਤੌਰ 'ਤੇ ਕਈ ਲੀਵਰਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ: ਮੰਗ ਦੀ ਵਾਧ ਨੂੰ ਢੀਲਾ ਕਰਨਾ (ਉਦਾਹਰਨ ਲਈ, ਦੁਹਰਾਈ ਗਈ ਬੇਨਤੀਆਂ ਨੂੰ ਸੀਮਿਤ ਕਰਨਾ), ਕੁਝ ਟ੍ਰਿਪ ਕਿਸਮਾਂ ਨੂੰ ਤਰਜੀਹ ਦੇਣਾ, ਅਤੇ ਮੇਚਿੰਗ ਲੋਜਿਕ ਨੂੰ ਅਡਜਸਟ ਕਰਨਾ ਤਾਂ ਕਿ ਚਰਨ (ਜ਼ਿਆਦਾ ਰੱਦ-ਕਿਰਿਆਵਾਂ ਅਤੇ ਮੁੜ-ਅਸਾਈਨਮੈਂਟ) ਘੱਟ ਹੋਵੇ। ਕੁਝ ਰਣਨੀਤੀਆਂ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦੀਆਂ ਹਨ ਕਿ ਬਲੋਚ/ਮੋੜ-ਢਾਂਚੇ ਨੂੰ ਪੂਰਾ ਕਰਨ ਨਾਲ ਵੱਡੇ ਖੇਤਰ ਵਿੱਚ ਪੁੱਖਤਤਾ ਖੋਹੀ ਨਾ ਜਾਵੇ।
ਜਦੋਂ ਹਾਲਾਤ ਅਸਥਿਰ ਹਨ, ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਸਾਫ਼ ਸੰਕੇਤ ਮਹੱਤਵਪੂਰਨ ਹਨ: ਵਾਸਤਵਿਕ ETA, ਪਾਰਦਰਸ਼ੀ ਕੀਮਤ ਬਦਲਾਅ, ਅਤੇ ਸਮਝਣਯੋਗ ਰੱਦ-ਨੀਤੀਆਂ। ਛੋਟੀ-ਛੋਟੀ ਸਪਸ਼ਟੀਕਰਨਾਂ ਵੀ "ਪੈਨਿਕ ਟੈਪਿੰਗ", ਗੈਰ-ਜਰੂਰੀ ਰੱਦ-ਕਿਰਿਆवਾਂ, ਅਤੇ ਦੁਹਰਾਈ ਬੇਨਤੀਆਂ ਨੂੰ ਘਟਾ ਸਕਦੀਆਂ ਹਨ—ਵਿਹਾਰ ਜੋ ਨੈੱਟਵਰਕ 'ਚ ਦਬਾਅ ਵਧਾ ਸਕਦੇ ਹਨ।
ਜਦੋਂ ਇੱਕ ਪਲੇਟਫਾਰਮ ਰੀਅਲ-ਟਾਈਮ ਵਿੱਚ ਕਾਰਾਂ ਨਿਰਦੇਸ਼ਿਤ ਅਤੇ ਕੀਮਤ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦਾ ਹੈ, ਉਹ ਇਹ ਵੀ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਕਿਸ ਨੂੰ ਸੇਵਾ ਮਿਲੇਗੀ, ਕਿੱਥੇ, ਅਤੇ ਕਿਹੜੀ ਕੀਮਤ 'ਤੇ। ਇਸ ਲਈ "ਸਿਸਟਮ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣਾ" ਇੱਕ ਅੰਕ 'ਤੇ ਹੀ ਨਿਰਭਰ ਨਹੀਂ ਹੋ ਸਕਦਾ।
ਨਿਆਂ ਦੇ ਮੁੱਦੇ ਰੋਜ਼ਾਨਾ ਨਤੀਜੇ ਵਿੱਚ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ:
ਕਿਸੇ ਵੀ ਪ੍ਰਾਇਸਿੰਗ ਜਾਂ ਡਿਸਪੈਚ ਐਲਗੋਰਿਦਮ ਦੇ ਖਾਸ ਨਿਰਣਾਂ ਵਿਚਲੀਆਂ ਲਕੜੀਆਂ ਨੂੰ ਤਰਜੀਹ ਦੈਂਦੀਆਂ ਹਨ—ਜਿਵੇਂ:
ਤੁਸੀਂ ਸਾਰੇ ਨੂੰ ਇੱਕੱਠੇ ਵਧਾ ਨਹੀਂ ਸਕਦੇ। ਜੋ ਕੁਝ ਅਪਟੀਮਾਈਜ਼ ਕਰਨਾ ਹੈ, ਉਹ ਇੱਕ ਨੀਤੀ ਫੈਸਲਾ ਹੋਣ ਦੇ ਨਾਲ-ਨਾਲ ਤਕਨੀਕੀ ਹੈ।
ਟ੍ਰਿਪ ਡੇਟਾ ਨਾਜ਼ੁਕ ਹੈ ਕਿਉਂਕਿ ਇਹ ਘਰ/ਦਫਤਰ ਦੇ ਪੈਟਰਨ, ਰੁਟੀਨ ਅਤੇ ਨਿੱਜੀ ਸਥਲਾਂ ਦੇ ਦੌਰੇ ਦਿਖਾ ਸਕਦਾ ਹੈ। ਜਿੰਮੇਵਾਰੀ ਵਾਲਾ ਤਰੀਕਾ ਡੇਟਾ ਘਟਾਉਣਾ (ਸਿਰਫ਼ ਜਿੰਨੀ ਲੋੜ ਹੋ), ਸੀਮਤ ਰਿਟੇਨਸ਼ਨ, ઔਕਸੈੱਸ ਕੰਟਰੋਲ ਅਤੇ ਨਾਜ਼ੁਕ GPS ਟ੍ਰੇਸਾਂ ਦੀ ਸਾਵਧਾਨ ਵਰਤੋਂ ਤੇ ਜ਼ੋਰ ਦਿੰਦਾ ਹੈ।
"ਭਰੋਸੇਯੋਗ ਸਿਸਟਮ" ਮਨੋਭਾਵ ਲਈ ਕੋਸ਼ਿਸ਼ ਕਰੋ:
ਜੇ ਤੁਸੀਂ ਬ੍ਰਾਂਡ ਅਤੇ ਐਪ ਹਟਾ ਦਿਓ, Uber ਦਾ "ਪ੍ਰੋਗ੍ਰਾਮੇਬਲ ਸ਼ਹਿਰ" ਅਸਰ ਤਿੰਨ ਲੀਵਰਾਂ 'ਤੇ ਚਲਦਾ ਹੈ ਜੋ ਲਗਾਤਾਰ ਚੱਲਦੇ ਅਤੇ ਇੱਕ-ਦੂਜੇ ਨੂੰ ਮਜ਼ਬੂਤ ਕਰਦੇ ਹਨ: ਲਿਕਵਿਡਿਟੀ, ਕੀਮਤ, ਅਤੇ ਡਿਸਪੈਚ/ਲੌਜਿਸਟਿਕਸ।
1) ਲਿਕਵਿਡਿਟੀ (ਸਹੀ ਸਮੇਂ/ਥਾਂ ਤੇ ਡੈਨਸਿਟੀ)। ਨੇੜੇ ਹੋਣ ਵਾਲੀ ਵਧੀਕ ਸਪਲਾਈ ਉਡੀਕ ਘਟਾਉਂਦੀ ਹੈ, ਜੋ ਪੂਰਨ ਯਾਤਰਾਂ ਨੂੰ ਵਧਾਉਂਦੀ ਹੈ, ਜੋ ਹੋਰ ਯਾਤਰੀ ਖਿੱਚਦੀ ਹੈ ਅਤੇ ਡ੍ਰਾਈਵਰਾਂ ਨੂੰ ਕਮਾਈ ਜਾਰੀ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ—ਇੱਕ ਆਪਸ ਵਿੱਚ ਮਿਲਣ ਵਾਲਾ ਲੂਪ ਬਣੌਂਦਾ ਹੈ।
2) ਕੀਮਤ (ਵਿਹਾਰ ਸਟੀਅਰ ਕਰਨਾ)। ਡਾਇਨਾਮਿਕ ਪ੍ਰਾਇਸਿੰਗ "ਉੱਚ ਕੀਮਤ" ਦੇ ਬਾਰੇ ਘੱਟ ਹੈ ਅਤੇ ਵੱਧ ਬਾਰੇ ਇਸ ਨੂੰ ਉਤਸ਼ਾਹਾਂ ਨੂੰ ਖਿੱਚਣ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ ਤਾਂ ਕਿ ਸਪਲਾਈ ਮੰਗ ਸਪਾਈਕ ਵੱਲ ਵਧੇ ਅਤੇ ਯਾਤਰੀ ਆਪਣੀ ਤਰਜੀਹ ਦਰਸਾਉਂ। ਠੀਕ ਕੀਤਾ ਗਿਆ, ਕੀਮਤ ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਰੱਖਦੀ ਹੈ; ਗਲਤ ਕੀਤਾ ਤਾਂ churn ਅਤੇ ਨਿਯਮਾਵਲੀ ਸਮੀਖਿਆ ਹੋ ਸਕਦੀ ਹੈ।
3) ਡਿਸਪੈਚ & ਲੌਜਿਸਟਿਕਸ (ਜੋ ਤੁਹਾਡੇ ਕੋਲ ਹੈ ਉਸ ਦਾ ਸਹੀ ਉਪਯੋਗ)। ਮੇਚਿੰਗ, ਰੂਟਿੰਗ ਅਤੇ ਰੀਪੋਜ਼ੀਸ਼ਨਿੰਗ ਕੱਚੇ ਸਪਲਾਈ ਨੂੰ ਵਰਤਣਯੋਗ ਸਪਲਾਈ ਬਣਾਉਂਦੇ ਹਨ। ਵਧੀਆ ETA ਅਤੇ ਸਮਾਰਟ ਮੇਚਿੰਗ ਆਮ ਤੌਰ 'ਤੇ ਲਿਕਵਿਡਿਟੀ "ਬਣਾ" ਦਿੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਬੇਕਾਰ ਸਮਾਂ ਅਤੇ ਰੱਦ-ਕਿਰਿਆਵਾਂ ਘਟਾਉਂਦੇ ਹਨ।
ਜਦੋਂ ਇਹ ਸਭ ਇਕੱਠੇ ਹੁੰਦੇ ਹਨ, ਤੁਸੀਂ ਇੱਕ ਸਧਾਰਨ ਫਲਾਈਵ੍ਹੀਲ ਵੀਖਦੇ ਹੋ: ਵਧੀਆ ਮੇਚਿੰਗ → ਤੇਜ਼ ਪਿਕਅਪ → ਉੱਚੀ ਕਨਵਰਜ਼ਨ → ਵਧੀਆ ਕਮਾਈ/ਉਪਲਬਧਤਾ → ਵਧੇਰੇ ਯਾਤਰੀ → ਹੋਰ ਡੇਟਾ → ਹੋਰ ਵਧੀਆ ਮੇਚਿੰਗ ਅਤੇ ਪ੍ਰਾਇਸਿੰਗ।
ਇਹੇ ਮਾਡਲ ਫੂਡ ਡਿਲੀਵਰੀ, ਫ੍ਰੇਟ, ਘਰੇਲੂ ਸੇਵਾਵਾਂ, ਇਵੈਂਟ-ਅਧਾਰਿਤ ਅਪੋਇੰਟਮੈਂਟ ਮਾਰਕੀਟਪਲੇਸਾਂ 'ਤੇ ਲੱਗਦਾ ਹੈ:
ਜੇ ਤੁਸੀਂ ਗਹਿਰਾਈ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ measure ਅਤੇ pricing primers ਲਈ blog/marketplace-metrics ਅਤੇ blog/dynamic-pricing-basics ਵੇਖੋ।
ਜੇ ਤੁਸੀਂ ਐਸਾ ਮਾਰਕੀਟਪਲੇਸ ਬਣਾ ਰਹੇ ਹੋ—ਰੀਅਲ-ਟਾਈਮ ਸਟੇਟ, ਪ੍ਰਾਇਸਿੰਗ ਰੂਲ, ਡਿਸਪੈਚ ਵਰਕਫਲੋਜ਼ ਅਤੇ ਗਾਰਡਰੇਲ—ਤਾਂ ਮੁੱਖ ਚੁਣੌਤੀ ਆਮ ਤੌਰ 'ਤੇ ਗਤੀ ਹੁੰਦੀ ਹੈ: ਖ਼ਿਆਲਾਂ ਨੂੰ ਇੱਕ ਕੰਮ ਕਰਨ ਵਾਲੀ ਉਤਪਾਦ ਵਿੱਚ ਇਸ ਤਰ੍ਹਾਂ ਬਦਲਨਾ ਕਿ ਤੁਸੀਂ ਵਿਹਾਰ ਅਤੇ ਮੈਟ੍ਰਿਕਸ 'ਤੇ ਦੋਹਰਾਅ ਕਰ ਸਕੋ। Koder.ai ਵਰਗੀਆਂ ਪਲੇਟਫਾਰਮਾਂ ਟੀਮਾਂ ਨੂੰ ਇਹ ਸਿਸਟਮ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰੋਟੋਟਾਈਪ ਅਤੇ ਸ਼ਿਪ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੀਆਂ ਹਨ—React ਬੇਕ-ਆਫਿਸ, Go/PostgreSQL ਬੈਕਐਂਡ, ਅਤੇ ਚੈਟ-ਡ੍ਰਿਵਨ ਵਰਕਫਲੋਜ਼ ਰਾਹੀਂ мобਾਈਲ ਐਪ—ਜਦ ਤੁਸੀਂ ਡਿਸਪੈਚ ਲੋਜਿਕ, ਇੰਸਪੈਕਟ ਡੈਸ਼ਬੋਰਡ ਜਾਂ ਪ੍ਰਾਇਸਿੰਗ ਰੂਲ ਕੰਫਿਗਰੇਸ਼ਨ ਟੈਸਟ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਬਿਨਾਂ ਠੀਕ-ਠਾਕ ਪਲੰਬਿੰਗ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦੇ।
ਕੀ ਮਾਪਣਾ ਹੈ: ਪਿਕਅਪ ETA (p50/p90), ਫਿਲ ਰੇਟ, ਰੱਦ-ਦਰ (ਪਾਸੇ-ਵਾਰ), ਉਪਯੋਗਤਾ/ਆਈਡਲ ਸਮਾਂ, ਕਬੂਲ ਦਰ, ਘੰਟੇ ਪੈਸਾ, ਪ੍ਰਾਇਸ ਮਲਟੀਪਲਾਇਰ ਵੰਡ, ਅਤੇ ਦੁਹਰਾਇਆ ਦਰ।
ਕੀ ਟਿਊਨ ਕਰਨਾ ਹੈ: ਮੇਚਿੰਗ ਨਿਯਮ (ਤਰਜੀਹ, ਬੈਚਿੰਗ), ਰੀਪੋਜ਼ੀਸ਼ਨ ਨੁੱਡਜ਼, ਇਨਸੈਂਟਿਵ ਡਿਜ਼ਾਈਨ (ਬੋਨਸ vs ਮਲਟੀਪਲਾਇਰ), ਅਤੇ ਉਹ “ਗਾਰਡਰੇਲ” ਜੋ ਅਤਿ ਨਤੀਜਿਆਂ ਨੂੰ ਰੋਕਦੇ ਹਨ।
ਕੀ ਸੰਚਾਰ ਕਰਨਾ ਹੈ: ਕੀ ਕੀਮਤ ਬਦਲਾਉਂਦੀ ਹੈ, ਭਰੋਸਾ ਕਿਵੇਂ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਅਤੇ ਉਪਭੋਗਤਾ ਕੀ ਕਰ ਸਕਦੇ ਹਨ (ਰੁਕੋ, ਪੈदल ਜਾਓ, ਸ਼ੈਡਿਊਲ ਕਰੋ, ਟੀਅਰ ਬਦਲੋ)। ਸਾਫ਼ ਵਿਆਖਿਆਵਾਂ "ਅਲਗੋਰਿਦਮ ਬੇਤਰਤੀਬੀ ਹੈ" ਦੀ ਡਰ ਨੂੰ ਘਟਾਉਂਦੀਆਂ ਹਨ—ਅਤੇ ਭਰੋਸਾ ਖੁਦ ਇੱਕ ਕਿਸਮ ਦੀ ਲਿਕਵਿਡਿਟੀ ਹੈ।
“ਪ੍ਰੋਗ੍ਰਾਮੇਬਲ” ਸ਼ਹਿਰ ਦਾ ਅਰਥ ਲITERAL ਤੌਰ 'ਤੇ ਸੋਫਟਵੇਅਰ ਨਹੀਂ ਹੈ—ਇਸਦਾ ਮਤਲਬ ਉਹ ਸ਼ਹਿਰ ਹੈ ਜਿੱਥੇ ਇੱਕ ਪਲੇਟਫਾਰਮ ਇਹ ਕਰ ਸਕਦਾ ਹੈ:
ਰਾਈਡ-ਹੇਲਿੰਗ ਇੱਕ ਸਾਫ਼ ਉਦਾਹਰਣ ਹੈ ਕਿਉਂਕਿ ਇਹ ਸੜਕ-ਪੱਧਰੀ ਅਵਸਥਾ ਨੂੰ ਮਸ਼ੀਨ-ਪਾਠਯੋਗ ਸੰਕੇਤਾਂ ਵਿੱਚ ਬਦਲਦਾ ਹੈ ਅਤੇ ਲਗਾਤਾਰ ਇਨ੍ਹਾਂ 'ਤੇ ਕਾਰਵਾਈ ਕਰਦਾ ਹੈ।
ਇੱਕ ਪ੍ਰੋਗ੍ਰਾਮੇਬਲ ਨੈੱਟਵਰਕ ਜੋੜਦਾ ਹੈ:
কੁੰਜੀ ਵਿਚਾਰ ਇਹ ਹੈ ਕਿ ਜਦੋਂ ਨਵੇਂ ਸੰਕੇਤ ਆਉਂਦੇ ਹਨ, ਫੈਸਲੇ ਲਗਾਤਾਰ ਅਪਡੇਟ ਹੁੰਦੇ ਹਨ।
ਕਿਉਂਕਿ ਇਨਪੁਟ ਅਸਥਿਰ ਹਨ ਅਤੇ ਹਿੱਸੇ-ਤਰ੍ਹਾਂ ਮਨੁੱਖੀ ਹੁੰਦੇ ਹਨ:
ਪਲੇਟਫਾਰਮ ਸਿਰਫ਼ ਸ਼ਹਿਰ ਦੀ ਪੇਸ਼ਗੋਈ ਨਹੀਂ ਕਰ ਰਿਹਾ—ਇਹ ਅਸਲ ਸਮੇਂ ਵਿੱਚ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਹੈ ਕਿ ਪ੍ਰਤੀਕਿਰਿਆ ਨਵੀਆਂ ਸਮੱਸਿਆਵਾਂ (ਜਿਵੇਂ ਤੇਜ਼ੀ ਨਾਲ ਉਲਟ-ਫੇਰ ਕੀਮਤਾਂ) ਨਾ ਪੈਦਾ ਕਰੇ।
ਲਿਕਵਿਡਿਟੀ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇੰਨੇ ਨੇੜੇ ਡ੍ਰਾਈਵਰ ਅਤੇ ਯਾਤਰੀ ਹਨ ਕਿ ਮੇਚਜ਼ ਤੇਜ਼ ਅਤੇ ਭਰੋਸੇਮੰਦ ਹੋਣ।
ਇਹ ਸਿਰਫ਼ "ਸ਼ਹਿਰ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਡ੍ਰਾਈਵਰ" ਨਹੀਂ—ਬਲਕਿ ਬਲਾਕ-ਵਾਰ ਅਤੇ ਪਲ-ਵਾਰ ਡੈਂਸਿਟੀ ਜ਼ਿਆਦਾ ਅਹਿਮ ਹੈ, ਕਿਉਂਕਿ ਦੂਰੀ ਵਾਧੇ ਨਾਲ:
ਲੋ ਲਿਕਵਿਡਿਟੀ ਆਦਤਨ ਇਹ ਰੂਪ ਲੈਂਦੀ ਹੈ:
ਇਹ ਆਲਾਮ ਇੱਕੋ ਹੀ ਘਾਟ ਦੀ ਵੱਖ-ਵੱਖ ਪੇਸ਼ੀਆਂ ਹਨ—ਨੇੜੇ ਉਪਲਬਧ ਕਾਰਾਂ ਦੀ ਘਾਟ।
ਡਾਇਨਾਮਿਕ ਪ੍ਰਾਇਸਿੰਗ ਨੂੰ ਇੱਕ ਸੰਤੁਲਨ ਸਾਧਨ ਵਜੋਂ ਵੇਖੋ—ਇਹ ਸਿਰਫ਼ "ਜ਼ਿਆਦਾ ਚਾਰਜ ਕਰਨ ਦਾ ਤਰੀਕਾ" ਨਹੀਂ ਹੈ। ਜਦੋਂ ਮੰਗ ਸਪਲਾਈ ਤੋਂ ਵੱਧ ਹੈ, ਉੱਚੀ ਕੀਮਤ:
ਜਦੋਂ ਅਸਮਤੁਲਨ ਘੱਟ ਹੁੰਦਾ ਹੈ, ਕੀਮਤ ਮੁੜ ਨਾਰਮਲ ਹੋ ਸਕਦੀ ਹੈ।
ਗਵਰਨਰ-ਰੇਲਾਈਨਸ ਨੂੰ ਡਿਜ਼ਾਈਨ ਦਾ ਹਿੱਸਾ ਬਣਾਉਣਾ ਲਾਜ਼ਮੀ ਹੈ। ਆਮ ਗਵਰਨਰ-ਰੇਲਜ਼ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
ਫ਼ਾਇਦਾ ਇਹ ਹੈ ਕਿ ਪ੍ਰਾਇਸਿੰਗ ਇੱਕ ਵਿਹਾਰਿਕ ਸੰਕੇਤ ਹੈ—ਇਹ ਮਾਰਕੀਟਪਲੇਸ ਨੂੰ ਵਰਤਣਯੋਗ ਰੱਖਣ ਲਈ ਹੈ, ਤਾਂ ਜੋ ਪਿਕਅਪ ਸੰਭਵ ਰਹਿਣ ਅਤੇ ਉਡੀਕ ਸਮੇ ਪਾਰ ਨਾ ਹੋ ਜਾਣ।
ਇਹ ਸਦਾ "ਬਸ ਨਜ਼ਦੀਕੀ ਡ੍ਰਾਈਵਰ ਨੂੰ ਦੇ ਦੇਵੋ" ਵਾਂਗ ਨਹੀਂ ਹੁੰਦਾ। ਮੇਚਿੰਗ ਅਕਸਰ ਵਿਚਾਰ ਕਰਦੀ ਹੈ:
ਵਧੀਆ ਮੇਚ ਉਹ ਹੁੰਦਾ ਹੈ ਜੋ ਮੌਜੂਦਾ ਯਾਤਰਾ ਨੂੰ ਸੁਧਾਰਦਾ ਹੋਵੇ ਬਿਨਾਂ ਅਗਲੇ ਕੁਝ ਮਿੰਟਾਂ ਦੀ ਪ੍ਰਣਾਲੀ ਨੂੰ ਬਿਗਾੜੇ।
ਪਲੇਟਫਾਰਮ ਇੱਕ "ਰਿਆਲ-ਟਾਈਮ ਸਟੇਟ" ਬਣਾਉਂਦਾ ਹੈ ਇਹਨਾਂ ਸੰਕੇਤਾਂ ਤੋਂ:
ਫੈਸਲੇ ਅਕਸਰ ਬੈਚਾਂ ਵਿੱਚ ਲਏ ਜਾਂਦੇ ਹਨ (ਕਈ ਸਕਿੰਟਾਂ ਵਿੱਚ), ਨਕਸ਼ੇ ਦੀਆਂ ਕੋਠੀਆਂ/ਸੈੱਲਾਂ 'ਤੇ, ਅਤੇ ਛੋਟੇ ਸਮੇਂ ਦੀਆਂ ਖ਼ਿੜਕੀਆਂ 'ਤੇ ਆਧਾਰਿਤ।
ਜਦੋਂ ਇੱਕ ਪਲੇਟਫਾਰਮ ਹਕੀਕਤ-ਵਾਰ ਰੇਅਲ-ਟਾਈਮ ਫੈਸਲੇ ਲੈਂਦਾ ਹੈ, ਇਹ ਉਨ੍ਹਾਂ ਨਤੀਜਿਆਂ ਨੂੰ ਵੀ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ—ਇਸ ਲਈ ਚੁੱਕੇ गए ਟੀਕੇ ਦੁਬਾਰਾ ਕੰਮ ਕਰਦੇ ਹਨ:
ਇਨਾਮਦਾਇਕ ਲੂਪ: ਚੰਗੇ ETA ਅਤੇ ਭਰੋਸੇਮੰਦ ਕੀਮਤਾਂ ਨਾਲ ਯਾਤਰੀ ਵੱਧ ਬੇਨਤੀਆਂ ਕਰਦੇ ਹਨ → ਡ੍ਰਾਈਵਰ ਦੀ ਆਮਦ ਬਿਹਤਰ ਹੁੰਦੀ ਹੈ → ਲਿਕਵਿਡਿਟੀ ਹੋਰ ਸੁਧਰਦੀ ਹੈ।
ਨੈਗੇਟਿਵ ਲੂਪ: ਜੇ ਰੱਦ-ਕਿਰਿਆਵਾਂ ਅਤੇ ਲੰਮੇ ਉਡੀਕਾਂ ਵਧਣ, ਯਾਤਰੀ ਐਪ 'ਤੇ ਭਰੋਸਾ ਘਟਾਉਂਦੇ ਹਨ → ਬੇਨਤੀਆਂ ਘੱਟ ਹੁੰਦੀਆਂ ਹਨ → ਡ੍ਰਾਈਵਰ ਆਨਲਾਈਨ ਘੱਟ ਹੋਣ ਜਾਂ ਖੇਤਰ ਛੱਡ ਦੇਂਦੇ ਹਨ → ਸੇਵਾ ਹੋਰ ਖਰਾਬ ਹੋ ਜਾਂਦੀ ਹੈ।
ਇਸ ਲਈ ਲਗਾਤਾਰ ਸਥਿਰਤਾ ਝੱਟ-ਪੀਕਸ ਤੋਂ ਜ਼ਿਆਦਾ ਕੀਮਤੀ ਹੁੰਦੀ ਹੈ।
ਆਮਤੌਰ 'ਤੇ ਪ੍ਰਦਰਸ਼ਨ ਅਨੁਮਾਨਿਤ ਤਰੀਕੇ ਨਾਲ ਚੱਲਦਾ ਹੈ, ਪਰ ‘ਏਜ ਕੇਸ’ ਉਹ ਹਨ ਜਦੋਂ ਪੈਟਰਨ ਟੁਟ ਜਾਂਦੇ ਹਨ:
ਮੁਹੰਮਮ ਦੀ ਮੋਚਵਾਰਤਾ ਇਹ ਹੈ ਕਿ ਸਿਗਨਲ ਦੇਰੀ ਵਾਲੇ ਜਾਂ ਨਾਪੂਰਨ ਹੋਣ 'ਤੇ ਕੋਆਰਡੀਨੇਸ਼ਨ ਸਭ ਤੋਂ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ।
ਜਦੋਂ ਅਲਗੋਰਿਦਮ ਰੀਅਲ-ਟਾਈਮ ਵਿੱਚ ਕਾਰਵਾਈ ਕਰਦੇ ਹਨ, ਇਹ ਠਹਿਰਾਅ ਤੇ ਕੀਮਤਾਂ ਦੁਆਰਾ ਇਹ ਫੈਸਲਾ ਕਰ ਸਕਦੇ ਹਨ ਕਿ ਕੌਣ ਮਿਲਦਾ ਹੈ, ਕਿੱਥੇ ਅਤੇ ਕਿਸ ਕੀਮਤ 'ਤੇ। ਇਸ ਲਈ “ਸਿਸਟਮ ਨੂੰ ਬੇਹਤਰ ਬਣਾਉਣਾ” ਇਕ ਅੰਕ ਨਹੀਂ ਹੋ ਸਕਦਾ।
ਗੁਪਤਤਾ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਟ੍ਰਿਪ ਡੇਟਾ ਘੱਟੋ-ਘੱਟ ਇਕੱਤਰ ਕਰੋ, ਰਿਟੇਨਸ਼ਨ ਸਮੇਂ ਸੀਮਿਤ ਰੱਖੋ, ਅਤੇ ਨਾਜ਼ੁਕ GPS ਨੋਟਸ ਦੀ ਸਾਵਧਾਨ ਵਰਤੋਂ ਕਰੋ।
