iOS의 지연된 딥 링크

Question

Google은 iOS 애플리케이션 중 하나에서 지연된 딥 링크를 구현하여 사용자가 친구를 초대하여 앱을 사용하도록 유도하고 추천 링크에서 발생하는 설치 수에 따라 사용자에게 보상을 제공합니다. 기본적으로 TapStream's product과 유사합니다.

그래서, 사용자 A가 그들이 원하는 네트워크에 자신의 링크, "ourappURL.com/refer?id=userA"를 공유 :

이 예를 생각해 보자. UserB가 해당 링크를 클릭하면 Safari로 이동 한 다음 UserB 이 앱을 다운로드하는 App Store 페이지로 이동합니다.

UserB가 앱을 열면 앱에서 이 온 참조 ID를 확인합니다 (있는 경우). 이 예에서 참조 ID는 참조 링크에 있던 ID가 인 "userA"입니다. 그러면 앱이 Google 서버의 에게이 정보를 전송하며 추천 신용으로 UserA를 선정합니다.

저는이 문제를 핵심 부분으로 분해하려고합니다. 첫 번째 부분은 사용자의 추천 링크에 대한 웹 페이지를 가져와 앱이 액세스 할 수있는 어딘가에 참조 ID를 저장한다고 생각합니다. 하지만 iOS의 샌드 박스 특성 때문에 이것이 가능하지는 않습니다.

많은 광고 제공 업체가 광고 캠페인 (예 : 모바일 앱 추적 참조)에서 설치를 추적 할 수 있기 때문에 이것이 근본적으로 가능함을 알고 있습니다.

Answer 1

우리는 또한이 작업을 스스로 시도했으며 여기서 다른 단계를 무너 뜨리려고합니다.

예제로 돌아 가면 장치 ID와 모든 관련 데이터 "id = userA"를 "기억"하는 것이 옳습니다. 또한 웹 페이지가 브라우저 앱 (Safari) 및 앱 (앱) 외부에 정보를 저장할 수 없다는 것을 의미하는 "샌드 박스가있는 iOS의 성격"에 대해 정확합니다. 다른 앱에 저장된 정보에 액세스 할 수 없습니다 원정 여행).

Google의 솔루션은 브라우저와 앱 (백엔드 서버)에서 모두 액세스 할 수있는 환경에서이 기기를 데이터 키 - 값 쌍에 저장하는 것입니다.

가장 큰 도전 과제 인 다음 과제는 브라우저에서 수집 할 수있는 정보에서이 장치를 고유하게 식별하는 방법입니다. 브라우저의 자바 스크립트는 기본 앱과는 달리 iOS 기기를 고유하게 식별하는 데 사용할 수있는 IDFA에 액세스 할 수 없습니다. 이를 극복하기 위해 브라우저 앱과 네이티브 앱 모두에서 사용할 수있는 공통 정보 (예 : OS 유형, 공개 IP, 화면 크기 등)를 조합하여 사용하는 방법을 생각해 볼 수 있습니다. 이 데이터 필드는 고유성을 보장하지 않습니다 (두 개의 iPhone 6이 동일한 라우터를 통해이 웹 페이지를 방문한다고 상상하십시오). 따라서 백엔드 서버 (이 키 - 값 쌍을 저장하는 데 사용한다고 가정)는 키 충돌을 처리하는 방법에 대한 전략을 원합니다. 즉, 두 번째 키가 첫 번째 키를 삭제하거나 충돌을 허용하려면 단일 키의 값 대기열 이것은 실제로 당신이이 기술을 어떻게 사용하는지에 달려 있습니다.

마지막 단계는 이전에 저장 한 값을 검색하기 위해 백엔드 서버에서 "조회"를 수행하기 위해 이전에 브라우저에서 사용한 것과 동일한 필드를 사용하여 앱에이 복합 키를 형성하는 것입니다.여기

가하는 단계를 요약 한 것입니다 example.com?inviter=1

사용이 방문 웹 페이지 P

:

1. 사용자 1 2는 아래의 링크를 전송하여 사용자 2를 초대합니다 P 구조와 서버의 아이폰 OS에 다음 키 - 값 쌍 전송 | 55.55.55.55을 | × 1334 750 -> inviter_id = 1
2. 사용자 2가 2 첫 출시되면 앱 스토어 및 다운로드하여 인앱
3. 로 이동 A, A는 S와 동일한 키를 사용합니다. (IP가 변경되지 않았다고 가정).
4. S는 2

희망이 도움을 초청이 키가 보상 사용자에게,의 말을하자, 한 5 점을 전달하고 사용하여 값 inviter_id = 1을 찾습니다!

편집 4월 24일 :

데릭이 의견을 언급 한 이후

, 내가 여기에 우리의 이야기를 마무리하기 위해이 기회를 잡을 것이다 그림.

내 대답의 시작 부분으로 돌아가서 우리는 을 시도하여을 시도했습니다. 우리는 현재의 시스템 아키텍처 (어쨌든 최적화되지 않았거나 이와 같은 딥 링크 데이터를 저장하고 분석하기 위해 최적화 될 예정 임)를 기반으로 작동하는 프로토 타입을 가지고 있었고 궁극적으로 추가 엔지니어링 리소스를이 프로젝트에 할당하지 않기로 결정했습니다.

이 일치 프로세스의 경험적 특성으로 인해 우리는이 프로젝트가 디버깅, 튜닝 및 최적화 된 ROI 감소를 필요로한다는 것을 발견했습니다. 더 중요한 것은, 우리는보다 전문화되어 있으며 우리보다 훨씬 나은 직업을 가진 다른 회사를 발견했습니다.

내부 시스템 사용을 중단 한 지 6 개월이 지났지 만, 우리는 그러한 결정을 내린 것에 대해 후회하지 않았습니다.

이 과정에서 우리는 Appsflyer, Adjust, TapStream의 여러 공급 업체와 협력하여 궁극적으로 Branch Metrics https://branch.io으로 끝났습니다.

다른 회사와 DIY를해야하는지 또는 다른 회사와 다시 협력해야하는지 여부는 구체적인 목표에 따라 다릅니다. 우리는 마침내 지점에 머물기로 결정했습니다. 다른 공급 업체가 지점을 완전히 무료로 사용하면서 월 500 달러에서 수천 달러까지 비용을 청구했을뿐만 아니라 제공 한 지원 수준도 비교할 수없는 수준이기 때문입니다.

는

Answer 2

HERE

애플에서 내 대답은 더 이상 딥 링크를 지원하지 않습니다. 이제 유니버설 링크라고하며 조금 다르게 작동합니다.

이제 애플은 더 이상 딥 링크에 대한 URI 체계를 지원하는 소스 개발자들은 iOS에서 제대로 딥 링크하기 위해 범용 링크를 구현해야합니다. 이미 URI 스킴을 사용하고 있다면 유니버설 링크로 전환하는 블로그를 확인하십시오.에서

: HERE

그리고 HERE 유니버설 링크 및 그들이있는 또 다른 기사입니다.

Answer 3

여기 좋은 해결책이있다 : http://blogs.innovationm.com/deferred-deep-linking-in-ios-with-universal-link/

기본 워크 플로우 :

• 사용자가 웹에서 도메인 링크를 선택가.
• 링크는 쿠키에 참조 ID를 설정합니다.
• 사용자가 앱 스토어로 리디렉션되었습니다.
• 앱 실행시 SFSafariViewController의 추천 페이지를로드하십시오.
• 쿠키에 대한 참조 페이지 검사가 있고 참조 ID가있는 앱으로 딥 링크를 호출합니다.

Answer 4

앱 스토어로 리디렉션을 처리하는 웹 페이지는 사용자가 앱을 다운로드하도록하기 전에 모바일 장치의 클립 보드에 붙여 넣기를 수행합니다. 앱이 설치되면 NSPasteboard를 사용하여 첫 번째 출시시 제대로 코딩 된 문자열을 확인합니다. 이 문자열에는 관심있는 텍스트 나 백엔드에서 흥미로운 데이터를 가져 오는 데 사용되는 토큰이 더 안전하게 포함될 수 있습니다. 목표 C에서 :

UIPasteboard *pasteboard = [UIPasteboard generalPasteboard]; 
NSString *pasteboardString = pasteboard.string; 

클립 보드는 동일한 작업을 반복하지 않도록 앱이 완료되면 삭제할 수 있습니다.