I'm a software engineer working for indeed.com, a job board helping users find a job. When jobseekers search for a job on Indeed, they're sometimes redirected to the employer's website to complete the application process. Indeed is very interested in knowing whether or not jobseekers complete the application process (e.g. to know if the jobs we're showing to users are pertinent enough that they will apply) and we're evaluating how this API could be used to do this in a privacy-preserving way. However, there is a major blocker in the current proposal, namely that the attribution logic only considers eTLD+1.
For employers who host job offers on their own domains, this is not an issue. However, the majority of employers use an Applicant Tracking System (ATS - such as Workday, Taleo, iCims...). In these cases, it's common for employers to be separated into subdomains of the ATS domain (i.e. employer.ats.com), or into different paths (i.e. ats.com/employer). Since the API's attribution logic cannot distinguish these domains, a user clicking on a job from company A and applying to a job from company B would trigger an attribution report. Without a way to distinguish these reports from legitimate ones, the only knowledge we can gleam from attribution reports is that a user both clicked and applied to jobs on the same ATS.
I understand that the limitation to eTLD+1 is in place to prevent privacy-breaking workarounds that rely on subdomains. However, I feel that the use case above is a legitimate one that isn't currently supported. I'm sure we're not the only ones with this use case - looking forward to hearing your thoughts on this issue.
Hi,
I'm a software engineer working for indeed.com, a job board helping users find a job. When jobseekers search for a job on Indeed, they're sometimes redirected to the employer's website to complete the application process. Indeed is very interested in knowing whether or not jobseekers complete the application process (e.g. to know if the jobs we're showing to users are pertinent enough that they will apply) and we're evaluating how this API could be used to do this in a privacy-preserving way. However, there is a major blocker in the current proposal, namely that the attribution logic only considers eTLD+1.
For employers who host job offers on their own domains, this is not an issue. However, the majority of employers use an Applicant Tracking System (ATS - such as Workday, Taleo, iCims...). In these cases, it's common for employers to be separated into subdomains of the ATS domain (i.e. employer.ats.com), or into different paths (i.e. ats.com/employer). Since the API's attribution logic cannot distinguish these domains, a user clicking on a job from company A and applying to a job from company B would trigger an attribution report. Without a way to distinguish these reports from legitimate ones, the only knowledge we can gleam from attribution reports is that a user both clicked and applied to jobs on the same ATS.
I understand that the limitation to eTLD+1 is in place to prevent privacy-breaking workarounds that rely on subdomains. However, I feel that the use case above is a legitimate one that isn't currently supported. I'm sure we're not the only ones with this use case - looking forward to hearing your thoughts on this issue.