Singapore traffic funnel — jodapp.com

Period: 1 May 2026 to 29 July 2026 (last 90 days) Filters: country = Singapore and hostName = jodapp.com Source: GA4 property properties/515821279 Written: 30 July 2026 Reviewed: independently re-run and audited before publishing

Read the funnel definition first. It explains what each event means and why these filters are needed.

Read this before you use any number

Four limits apply to everything below. They are not small.

1. The "clicked Apply" step is not measured. The app sends an event called job_apply_start. GA4 has never received one. So we can see people arrive at a job, and we can see the few who finish an application, but we cannot see who tried. This is the biggest gap.
2. Gig applications do not happen on this site. About 70% of job views here are gig jobs. Those workers finish on gig-partners.jodapp.com. This report filters that site out, as requested.
3. The Singapore filter is narrow. It removes about 46% of all jodapp.com sessions and 80% of all careers applications. See "What the Singapore filter hides" below. This matters for budget decisions.
4. Every rate here is measured among people who entered at step 1. GA4 funnel reports are closed and ordered. Between 23% and 37% of mid-funnel users are excluded by that rule. Sizes are given below.

TL;DR

• Sessions are growing, but job viewers fell 25% from June to July while sessions rose 17.5%. That is the most urgent signal in this report.
• About 41% of visits reach a job page. That step is healthy.
• Of careers job views, 0.68% became an application. That is 45 applications from 6,614 job views in 90 days.
• Careers job cards are not worse than gig cards. In search results they perform at near parity (7.71% against 8.21%). The earlier reading of a large gap was a mix effect, not a quality gap.
• The homepage careers module is the real problem. It produced 40,275 job card views and only 323 clicks — a 0.80% click rate. The gig module on the same page gets 3.63%.
• Singapore is only 20% of careers applications. The Philippines produced more than twice as many.
• We still cannot say why people do not apply, because the Apply click is not tracked. Fix that before changing spend.

Step 1 — Where traffic comes from

Sessions in the period: 21,582.

Channel	Sessions	Share
Direct	11,681	54.1%
Organic Search	3,468	16.1%
Paid Search	3,381	15.7%
Unassigned	1,017	4.7%
Email	745	3.5%
Referral	536	2.5%
Cross-network	377	1.7%
Organic Social	172	0.8%
Display	123	0.6%
AI Assistant	65	0.3%
Paid Video	17	0.1%

Direct is more than half of all sessions. That share is high for a job board. It usually means one of two things:

• Returning workers type the address or use a saved link. This is good.
• Some traffic loses its source tag on the way in. This would hide the true value of paid and email work.

We have not proved which. It is an open question below.

Step 2 — The main funnel

This uses activeUsers, the user count GA4 applies inside funnel reports.

Step	Event	Users	Continue to next step
1. Landed	session_start	10,247	40.7%
2. Viewed a job	view_item	4,174	0.41%
3. Applied	generate_lead	17	—

How much the closed funnel leaves out

A GA4 funnel only counts people who did every step in order, starting at step 1. Anyone who was already mid-journey is dropped. Here is the size of that effect.

Event	Counted in funnel	All users with that event	Excluded
session_start	10,247	13,251	22.7%
view_item	4,174	5,621	25.7%
select_item	1,299	1,907	31.9%
generate_lead	17	27	37.0%

Read every funnel rate as "among people who started here in this window". The direction is right. The absolute counts are low by roughly a quarter.

Split by device

Device	Landed	Reached a job	Rate
Mobile	6,441	3,084	47.9%
Desktop	3,761	1,081	28.7%
Tablet	37	9	24.3%

Mobile users are much more likely to reach a job page. This difference is large and reliable.

Do not split the apply step by device. Only 13 mobile and 4 desktop users applied. Those counts are far too small to compare.

Step 3 — The discovery funnel

This measures the job list, which the main funnel skips on purpose.

Step	Event	Users	Continue
1. Saw a job list	view_item_list	4,217	30.8%
2. Clicked a job card	select_item	1,299	99.6%
3. Job detail loaded	view_item	1,294	1.2%
4. Applied	generate_lead	16	—

Two readings:

• The click-to-page step works. 99.6% of clicks load the page. There is no broken link or slow page problem here.
• Only 30.8% of people who see a list click anything in it.

Step 4 — Which job cards get clicked

This is the section that changed most after review. The first version compared careers against gig in total and found a large gap. That gap was a mix effect. Splitting by the list a card appears in tells a different story.

These are event counts, not people.

Surface	Job type	Cards shown	Clicks	Click rate
Search results	Gig::Job	138,070	11,337	8.21%
Search results	Careers::Job	19,972	1,539	7.71%
Home — gig module	Gig::Job	10,260	372	3.63%
Home — careers module	Careers::Job	40,275	323	0.80%
McDonald's page	Gig::Job	5,710	136	2.38%

Three findings:

• In search results, careers cards match gig cards. 7.71% against 8.21% is near parity. There is no careers card quality problem in search.
• The homepage careers module is the weak point. It is the single largest source of careers card views on the site — 40,275 of 60,247, which is 67%. It converts at 0.80%. The gig module directly beside it gets 3.63%, which is 4.5 times better.
• The totals still hold: gig cards 154,040 shown and 11,845 clicked; careers cards 60,247 shown and 1,862 clicked. The aggregate gap is real but it is caused by where careers cards are shown, not by the cards themselves.

Why this matters

The obvious action from the first version was "rewrite careers job cards". That would have been wasted work. The correct action is to fix or replace the homepage careers module.

Step 5 — Gig against careers

view_item covers both job types. generate_lead on this site covers careers only.

Job type	Job pages viewed	Share of views
Gig::Job	15,452	70.0%
Careers::Job	6,614	30.0%

The careers conversion rate

Measure	Value
Careers job pages viewed (events)	6,614
Careers applications (events)	45
Conversion, by events	0.68%
Conversion, by users (approximate)	about 0.8%

The events-based figure is the reliable one. Each view_item carries exactly one item, and generate_lead carries no items, so neither can double-count. A user-based split by job type is only approximate, because item data is attached to events, not to people.

Comparing to gig-partners

gig-partners.jodapp.com recorded 730 generate_lead events from 130 Singapore users in the same 90 days. jodapp.com recorded 45 events from 27 users.

Do not read that as "gig is 16 times bigger". The two events count different things:

• A gig worker applies per shift, so one user fires many events. The average is 5.6 events per user.
• A careers worker applies per job. The average is 1.67 events per user.

By people the gap is 130 against 27, which is about 4.8 times. That is the fair comparison.

Step 6 — Trend over time

Users per month, Singapore, jodapp.com.

Month	Visits started	Viewed a job	Applied
Feb 2026	2,248	518	0
Mar 2026	3,929	1,292	1
Apr 2026	3,401	1,022	2
May 2026	3,571	1,407	9
Jun 2026	4,871	2,617	7
Jul 2026	5,725	1,963	11

The upper line is visits started. The lower line is people who viewed a job.

The June to July drop

Sessions kept rising, but job viewers fell.

Measure	June	July	Change
Visits started	4,871	5,725	+17.5%
Viewed a job	2,617	1,963	−25.0%
Share reaching a job	53.7%	34.3%	−19.4 points

July covers 29 days against June's 30. Adjusting for that still leaves a fall of about 22%.

More people arrived and fewer reached a job. Possible causes are a change in traffic mix, fewer live jobs, or a site change. This needs checking before any spend decision. January 2026 is left out because the property only began collecting data on 9 December 2025.

What the Singapore filter hides

You asked to filter to Singapore. That is a fair business scope, but you should know what it removes. All careers applications on jodapp.com, 90 days, by country:

Country	Applications (events)	Users	Share of events
Philippines	101	31	45.1%
Singapore	45	27	20.1%
India	21	5	9.4%
Malaysia	21	8	9.4%
Indonesia	19	6	8.5%
All others	17	12	7.6%
Total	224	—	100%

The Singapore filter also removes about 46% of all jodapp.com sessions.

Be careful how you read the Philippines number. It converts at a much higher rate than Singapore. That is not automatically a growth opportunity. Most jobs on the platform need the right to work in Singapore. Those 31 users each applied about 3.3 times, which is a pattern seen in bulk applying. Before treating this as a market, check with the operations team how many of these applications were usable. If most are not, the correct action is to filter them out, not to target them.

What we cannot see, and why it matters

The app has an event for the Apply click, named job_apply_start. It was added to the code on 15 January 2026. It fires for both careers and gig jobs. GA4 has received zero of these events across the whole life of the property.

Four more events behave the same way: login, sign_up, search and share. All five are written in the app. None arrive.

The cause is now confirmed. Container GTM-NKWB9VWN was inspected on 2026-07-30. One generic tag forwards our app events, but the trigger that fires it only matches seven event names, and none of the five silent events are in that list. The same list still allows add_to_cart, which the app stopped sending in January 2026. The app was updated and the GTM trigger was not.

The fix is one trigger pattern plus one new tag for the non-ecommerce events. See the funnel definition for the detail, and jodapp-web issue #1349 for the work.

There are also gates in the apply flow that send no event. After a worker clicks Apply on a careers job:

• A confirmation box opens, asking "Are you sure?". Some people stop here.
• If not logged in, the worker is sent to /login.
• If the career profile is not finished, the worker is sent to /talent/setup.

Note that job_apply_start fires when the confirmation box opens, not when the worker confirms. Once the tag is added, treat it as "opened the apply box", not "tried to apply".

So today we cannot answer the marketing question directly. These two stories fit the same data:

Story	What the data would look like	What we would do
Workers are not interested in these jobs	Few Apply clicks	Fix job supply and job cards
Workers try but the signup blocks them	Many Apply clicks, few finished	Fix login and profile setup

Both look identical right now.

Recommended actions

#	Action	Owner	Why
1	Add job_apply_start to the GTM trigger pattern	Engineering	One field edit. Without it we cannot tell a demand problem from a signup problem
2	Find out why job viewers fell 25% from June to July	Marketing + Eng	Largest live movement in the data
3	Fix or replace the homepage careers module	Marketing + Eng	40,275 card views at 0.80%, against 3.63% for the gig module beside it
4	Send an event when the login or profile gate blocks an apply	Engineering	Measures the invisible gates
5	Add one GTM tag for login, sign_up, search, share	Engineering	Four more measured steps, no app change needed
6	Check with operations whether offshore applications are usable	Marketing + Ops	80% of applications are non-Singapore; decide whether to filter or serve them
7	Check why Direct is 54% of sessions	Marketing	May be hiding the true value of paid and email
8	Register job_type and user_group as custom dimensions	Engineering	The app already sends them; GA4 has none registered, so they cannot be used in reports

Actions 1 and 2 come before any campaign decision. Changing spend now would be a guess.

Assumptions made in this report

Every one was checked against the code or the data, then re-checked in an independent audit.

#	Assumption	How it was checked	Risk if wrong
1	generate_lead on jodapp.com means one careers application	job-detail-page.jsx:173 fires it only after the application API call succeeds. All 45 Singapore events land on careers job paths	Low
2	Gig applications never fire generate_lead on jodapp.com	Same file. Gig clicks redirect to gig-partners first	Low
3	view_item covers both job types	itemCategory returns both Gig::Job and Careers::Job	Low
4	job_apply_start missing is a real gap, not a new deploy	Git history: added 2026-01-15, over six months ago	Low
5	The cause is a GTM configuration gap	Confirmed 2026-07-30. The container was read through the Tag Manager API. The trigger pattern excludes all five events	Low
6	itemsViewed equals job detail views	Totals 22,066, matching the view_item event count exactly	Low
7	The item split is not polluted by the missing ecommerce: null reset	Checked. itemsViewed matches view_item exactly, and itemsClickedInList (13,707) matches select_item exactly. Exactly 1.000 items per event. No leak found	Low
8	Singapore filter uses reported geography	GA4 infers country from IP address. VPN users are misplaced. (not set) country is only 76 sessions, so this is small	Low
9	The 90-day window is representative	It is not. Traffic and job views moved sharply within the window. Always read the monthly table too	Medium
10	hostName = "jodapp.com" captures the whole site	Exact match. It drops www., jobs. and careers. subdomains, worth about 1,068 sessions over 365 days. Small but real	Low

Open questions

• Does the real application count in the database match 45 for Singapore in this period? If the database shows many more, then generate_lead is also under-firing. This needs a query against production.
• Why did job viewers fall 25% from June to July?
• How many offshore applications are usable? This decides whether action 6 means filter or serve.
• Why is Direct 54% of sessions?

Answered since the first draft

Does cross-domain tracking work between the two sites? Yes. An earlier draft said only 349 sessions on gig-partners were tagged as coming from jodapp.com and treated that as a tracking failure. That reading was wrong.

• Those 349 sessions come from utm_source=jodapp.com, which the app only adds to login links. They were never meant to measure job handoffs.
• The GA4 cross-domain linker is active. Links carry the _gl= parameter. When the linker works, the session continues and the source stays as the original one, so a low count of "jodapp.com" as a source is the expected result.
• The gig handoff is measurable a different way. Gig job pages on gig-partners received 6,179 views in 90 days, and 6,069 of them — 98.2% — carry the listing_job_id parameter that jodapp.com adds to the redirect. That is 1,885 users making the crossing.

Use listing_job_id to measure the gig handoff. Do not use session source.