분석 SDK란 무엇입니까? 정의, 예제 및 올바른 SDK를 선택하는 방법

요약:

분석 SDK를 사용하면 SaaS 팀이 모든 것을 처음부터 구축하지 않고도 대시보드, 보고서 및 데이터 탐색을 제품에 직접 임베드할 수 있습니다. 제품이 팀, 프레임워크 및 지역에 걸쳐 확장됨에 따라 분석은 단순한 기능 그 이상이 됩니다. 인프라가 됩니다. 이 시점에서 유연성, 성능 및 제어는 선택 사항이 아닙니다. 많은 솔루션은 초기에 유사하게 보이지만 제품이 성장함에 따라 개발 속도를 늦추거나 아키텍처 선택을 제한하는 제약 조건을 도입합니다. 최신 분석 플랫폼은 팀이 도구에 제품을 맞추도록 강요하지 않고 여러 프레임워크, AI 기반 상호 작용 및 확장 가능한 배포를 지원해야 합니다.

주요 내용:

분석 SDK를 사용하면 대시보드와 보고서를 제품에 직접 임베드할 수 있습니다.
분석은 빠르게 기능에서 공유 인프라로 발전합니다.
iFrame, API 및 SDK는 서로 다른 장단점을 제공합니다.
제약은 확장에 따라 더 늦게 나타나는 경우가 많습니다.
최신 솔루션은 여러 프레임워크와 AI 사용 사례를 지원해야 합니다.
올바른 접근 방식은 장기적인 복잡성을 추가하지 않고 팀에 제어 권한을 부여합니다.

Reveal을 직접 사용해 보세요.

미리 녹화된 데모를 시청하여 Reveal을 즉시 임베드하는 간편함을 확인하십시오.

데모 시청

요약:

주요 내용:

분석 SDK를 사용하면 대시보드와 보고서를 제품에 직접 임베드할 수 있습니다.
분석은 빠르게 기능에서 공유 인프라로 발전합니다.
iFrame, API 및 SDK는 서로 다른 장단점을 제공합니다.
제약은 확장에 따라 더 늦게 나타나는 경우가 많습니다.
최신 솔루션은 여러 프레임워크와 AI 사용 사례를 지원해야 합니다.
올바른 접근 방식은 장기적인 복잡성을 추가하지 않고 팀에 제어 권한을 부여합니다.

대부분의 팀은 분석을 제품으로 제공하는 데 필요한 사항을 과소평가합니다.

처음에는 간단한 대시보드로 시작하지만 빠르게 데이터 인프라, 권한, 성능 및 UX 복잡성으로 확장됩니다. 대부분의 맞춤형 분석 작업은 여기서 실패합니다.

사용자는 애플리케이션을 벗어나지 않고 데이터를 보고 작업할 수 있기를 기대합니다. 분석이 없거나 연결되지 않으면 채택률이 떨어지고 사용자는 외부 도구를 사용합니다. 이러한 압력은 팀이 분석을 핵심 제품 경험으로 가져오도록 유도합니다.

문제는 단순해 보이는 것이 빠르게 확장된다는 것입니다. 팀은 데이터 파이프라인, 권한 로직 및 배포 속도를 늦추는 프런트 엔드 작업에 직면합니다.

이때 분석 SDK가 접근 방식을 변경합니다. 모든 것을 처음부터 구축하는 대신 팀은 분석을 제품에 직접 통합하고 제어권을 잃지 않으면서 더 빠르게 진행합니다.

분석 SDK란 무엇입니까?

분석 SDK는 SaaS 팀이 대시보드, 보고서 및 데이터 탐색을 제품에 직접 임베드할 수 있도록 하는 개발자 도구 세트입니다.

데이터, 애플리케이션 및 사용자 간의 브리지 역할을 하며 분석이 제공, 표시 및 제어되는 방식을 처리합니다.

개발자는 분석을 처음부터 구축하는 대신 애플리케이션 내에서 데이터 시각화, 사용자 상호 작용 및 액세스 제어를 처리하는 사전 구축된 레이어를 통합합니다.

일반적인 분석 SDK에는 다음이 포함됩니다.

대시보드 및 시각화 구성 요소
여러 데이터 소스에 대한 데이터 연결
맞춤 설정 및 제어를 위한 API
필터링 및 드릴다운과 같은 사용자 상호 작용

이러한 구성 요소는 애플리케이션 내에서 실행되며 아키텍처와 일치합니다. 분석은 제품의 일부가 되어 별도의 레이어가 되지 않습니다.

모든 솔루션이 동일하게 작동하는 것은 아닙니다.

일부 솔루션은 분석을 통합하거나 맞춤 설정할 수 있는 방법을 제한합니다. 다른 솔루션은 확장에 따라 더 늦게 나타나는 제약 조건을 도입하여 변경 사항이 비용이 많이 들고 관리하기 어려워집니다.

SDK 대 API 대 iFrame

팀은 일반적으로 분석 SDK를 선택하는 것으로 시작하지 않습니다. 팀은 가능한 한 빨리 제품에 대시보드를 추가하려고 시도하는 것으로 시작합니다. 일반적으로 iFrame, API 또는 SDK라는 세 가지 접근 방식으로 이어지며 각각 다른 장단점이 있습니다.

접근 방식	제어	UX	개발 노력	가장 적합한 대상
iFrame	낮음	불량	낮음	예산과 간단한 분석 요구 사항이 제한된 소규모 팀
API	높음	맞춤형	높음	전담 엔지니어링 리소스를 통해 완전히 맞춤형 분석 환경을 구축하는 팀
SDK	높음	기본	중간	완전한 제어 및 더 빠른 배포를 통해 분석을 임베드하는 SaaS 제품

.sdk-table-header-controls { display: flex; justify-content: flex-end; align-items: center; margin-bottom: 10px; position: relative; } .sdk-expand-icon { background: #fff; color: white; border: none; border-radius: 6px; width: 40px; height: 40px; cursor: pointer; display: flex; align-items: center; justify-content: center; transition: all 0.3s ease; backdrop-filter: blur(4px); opacity: 1; visibility: visible; transform: translateY(0); position: relative; z-index: 10; } .sdk-expand-icon:hover { background: #fff; transform: scale(1.1); } .sdk-expand-icon img { transition: transform 0.2s ease; } .sdk-expand-icon:hover img { transform: scale(1.1); } .sdk-table-responsive-sm { overflow-x: auto !important; -webkit-overflow-scrolling: touch; max-width: 100vw; position: relative; border: none; border-radius: 0.375rem; box-shadow: inset -5px 0 11px 1px #00000014; transition: all 0.5s ease; } .sdk-table-expanded { position: fixed !important; top: 0; left: 0; width: 100vw !important; height: 100vh !important; z-index: 999999; background: rgba(255, 255, 255, 0.95); margin: 0 !important; border-radius: 0 !important; box-shadow: none !important; overflow: auto !important; padding: 40px 20px 20px 20px; backdrop-filter: blur(10px); -webkit-backdrop-filter: blur(10px); display: flex; align-items: center; justify-content: center; } .sdk-table-expanded .sdk-table-responsive-sm { max-width: 95vw !important; max-height: 85vh !important; overflow: auto !important; border-radius: 8px !important; box-shadow: 0 10px 30px rgba(0, 0, 0, 0.3) !important; background: white !important; z-index: 1; } .sdk-table-expanded .sdk-comparison-table { min-width: auto !important; width: 100% !important; margin: 0 !important; position: relative !important; top: auto !important; left: auto !important; transform: none !important; max-height: none !important; } .sdk-table-expanded .sdk-comparison-table th, .sdk-table-expanded .sdk-comparison-table td { white-space: normal !important; word-wrap: break-word; max-width: none !important; padding: 15px 10px !important; font-size: 14px; } .sdk-table-expanded .sdk-table-header-controls { display: none !important; } .sdk-close-expanded { position: fixed; top: 20px; right: 20px; z-index: 1000000; background: #dc3545; color: white; border: none; border-radius: 50%; width: 50px; height: 50px; font-size: 20px; cursor: pointer; box-shadow: 0 4px 8px rgba(0, 0, 0, 0.2); transition: all 0.3s ease; } .sdk-close-expanded:hover { background: #c82333; transform: scale(1.1); } .sdk-comparison-table { min-width: 100% !important; width: 100%; table-layout: fixed; margin-bottom: 0; position: relative; } .sdk-comparison-table th, .sdk-comparison-table td { padding: 12px 8px !important; min-width: 50px; border: none !important; text-overflow: initial; overflow: visible; white-space: normal; word-break: break-word; } .sdk-comparison-table th:last-child, .sdk-comparison-table td:last-child { width: 220px; min-width: 220px; max-width: 220px; } .sdk-comparison-table th { background-color: #f8f9fa; font-weight: 600; position: sticky; top: 0; z-index: 10; } .sdk-comparison-table tr th { background: #666; color: #fff; } .sdk-comparison-table tr td { border: none !important; z-index: 1; position: relative; } .sdk-comparison-table td:first-child, .sdk-comparison-table th:first-child { position: sticky !important; left: 0; z-index: 5; min-width: 130px; font-weight: 600; border: none !important; overflow: visible; } .sdk-comparison-table td:first-child::after, .sdk-comparison-table th:first-child::after { content: ""; position: absolute; top: 0; right: 0; bottom: 0; width: 10px; pointer-events: none; border-right: 1px solid #ccc; box-shadow: 10px 0px 10px 0px #00000014; } .sdk-comparison-table tbody tr:nth-of-type(odd) td:first-child { background-color: #fff !important; } .sdk-comparison-table tbody tr:nth-of-type(even) td:first-child { background-color: #f5f6fb !important; } .sdk-comparison-table tbody tr:nth-of-type(even) td { background-color: #f5f6fb; } .sdk-comparison-table tbody tr:nth-of-type(odd) td { background-color: #fff; } .sdk-comparison-table th:first-child { background-color: #ec417a !important; z-index: 15; color: #fff; width: 130px; } .sdk-table-responsive-sm::after { content: ”← Swipe to see more →”; display: block; text-align: center; font-size: 12px; color: #6c757d; padding: 8px; background-color: #f8f9fa; border-top: 1px solid #dee2e6; } .sdk-table-expanded::after { display: none !important; } @media (min-width: 1200px) { .sdk-table-responsive-sm::after { display: none; } } @media (max-width: 768px) { .sdk-expand-icon { width: 35px; height: 35px; } .sdk-table-expanded { padding: 10px; } .sdk-table-expanded .sdk-comparison-table th, .sdk-table-expanded .sdk-comparison-table td { font-size: 12px; padding: 8px 5px !important; } }

iFrame

구현 속도가 가장 빠르지만 제한적입니다.

최소한의 맞춤 설정
사용자 경험이 단절됨
상호 작용에 대한 통제력이 부족함

API

완전한 통제권을 제공하지만 모든 책임을 귀사의 팀에 전가합니다.

처음부터 대시보드와 상호 작용을 구축해야 함
지속적인 유지 관리 및 복잡성
장기적으로 전달 속도가 느려짐

SDK

속도와 통제력 사이의 균형을 맞춤

사용자 정의가 가능한 사전 제작된 구성 요소
귀사의 제품에 기본적으로 통합됨
유연성을 저해하지 않으면서 더 빠른 전달이 가능함

Embedding analytics with iFrames vs. Native Analytics SDK

분석이 제품 경험의 일부가 됨에 따라 대부분의 SaaS 팀은 두 가지 극단적인 방법의 단점을 피하기 위해 SDK 기반 접근 방식을 채택합니다. 차이점은 다음을 비교할 때 더욱 명확해집니다. 제품 내 분석 대 iFrame 실제 제품 시나리오에서.

분석 SDK 작동 방식

제품 내 분석은 단순히 시각적 계층이 아닙니다. 모든 상호 작용은 데이터에 액세스, 보호 및 실시간으로 전달되는 방식에 따라 달라집니다. 분석 SDK는 이러한 요소를 귀사의 애플리케이션 내에 통합하여 팀이 처음부터 끝까지 분석의 동작을 제어할 수 있도록 합니다.

클라이언트 측

클라이언트 측에서 SDK는 사용자가 보고 상호 작용하는 모든 것을 처리합니다.

UI 내에 렌더링된 대시보드 및 시각화
사용자 상호 작용을 위한 필터 및 드릴다운
사용자 입력에 기반한 실시간 업데이트

이 계층은 분석이 제품의 기본 부분이 되도록 보장하며, 외부 도구가 아닙니다.

서버 측

서버 측에서 SDK는 데이터에 액세스하고 전달하는 방식을 관리합니다.

귀사의 데이터에 대한 쿼리가 실행됨 데이터 소스
사용자별로 권한 로직이 적용됨
실시간 응답에 최적화된 성능

이 계층은 분석을 귀사의 데이터 소스에 연결하고 귀사의 애플리케이션의 나머지 부분과 동일한 규칙을 적용합니다.

이러한 계층은 데이터가 이동하고 상호 작용이 작동하는 방식을 제어하는 API를 통해 통신합니다. 개발자는 전체 분석 스택을 다시 구축하지 않고도 경험을 조정할 수 있습니다. 이를 통해 팀은 유연성을 유지하면서 아키텍처 일관성을 유지할 수 있습니다.

SaaS 팀의 경우 이 모델은 임베디드 분석 여러 애플리케이션에서 확장하기가 더 쉬워집니다. 분석은 귀사의 제품과 일치하며 팀은 전체 시스템을 구축하고 유지 관리하는 데 드는 부담을 피할 수 있습니다.

SaaS 기업이 분석 SDK가 필요한 이유

어느 시점에서 모든 SaaS 팀은 동일한 문제에 직면합니다. 분석은 기능으로 시작하지만 빠르게 고객, 데이터 세트 및 사용 사례 전반에 걸쳐 확장해야 하는 인프라가 됩니다.

Benefits of adding analytics SDK into your application

변하는 것은 규모뿐만 아니라 기대치입니다.

고객별 테넌트 수준의 데이터 격리
더 큰 데이터 세트에서 성능 향상
다양한 사용 사례에 대한 유연한 전달
원활한 제품 내 경험

대부분의 팀은 이러한 변화가 얼마나 빨리 일어나는지 과소평가합니다.

몇 개의 대시보드를 출시한 다음 고객이 액세스 권한을 요청합니다. 권한, 성능 및 확장성은 빠르게 지속적인 작업으로 바뀝니다. 그 시점에서 분석은 더 이상 기능이 아닙니다. 유지 관리해야 하는 것으로 변합니다.

분석 SDK는 팀에게 이를 처리할 수 있는 구조화된 방법을 제공합니다. 각 사용 사례에 대한 로직을 다시 구축하는 대신 일관된 계층을 사용하여 제품에 맞게 조정합니다.

Datacom 은 좋은 예입니다. 이 팀은 Reveal 분석을 플랫폼에 통합하여 사용자가 애플리케이션을 벗어나지 않고도 실시간으로 데이터를 확인할 수 있도록 했습니다. 이를 통해 개발 오버헤드를 늘리지 않고 분석을 확장할 수 있었습니다.

대부분의 분석 SDK의 숨겨진 제한 사항

분석 SDK를 평가하는 팀은 종종 제품 내 분석 기능 목록에 중점을 둡니다. 처음에는 대부분의 플랫폼이 유사하게 보입니다. 대시보드, 통합 및 설정은 비교적 유사하게 보입니다.

차이점은 실제 구현 중에 나타납니다.

일반적인 제한 사항은 다음과 같습니다.

제한된 프레임워크 지원: 일부 도구는 하나의 프레임워크만 지원하므로 팀이 스택을 조정하거나 불일치를 발생시켜야 합니다.
부분적인 SDK: 대부분은 API에 크게 의존하므로 개발자는 여전히 분석 경험의 핵심 부분을 구축해야 합니다.
통합 제약 조건: 분석은 제품의 기본 부분이 아니라 별도의 시스템처럼 작동합니다.
확장 문제: 성능, 다중 테넌트 및 데이터 복잡성을 시간이 지남에 따라 관리하기 어려워집니다.

이러한 문제는 초기 데모에서는 거의 나타나지 않습니다. 분석이 핵심 제품의 일부가 되어 팀, 애플리케이션 및 고객 전반에 걸쳐 확장해야 할 때 문제가 발생합니다. 이때 제품 내 분석의 유연성 이 결정적인 요소가 됩니다.

SaaS 기업의 다중 프레임워크 현실

SaaS 회사는 일반적으로 단일 프레임워크에서 운영하지 않습니다. 제품이 성장하고 팀이 지역 전반으로 확장됨에 따라 각 팀은 전문 지식과 가용성에 따라 다른 기술을 사용합니다.

일반적인 다중 프레임워크 설정

미국 팀에서 Angular로 구축된 하나의 애플리케이션
유럽 팀에서 React로 개발된 또 다른 제품
.NET 워크로드를 위해 Blazor에서 실행되는 세 번째 시스템

팀은 채용 가능성, 기존 시스템 및 전달 속도를 기반으로 프레임워크를 선택합니다. 시간이 지남에 따라 제품 전반에 걸쳐 다중 프레임워크 환경이 생성됩니다.

대부분의 분석 SDK 도구는 이 환경에서 작동하지 않습니다. 단일 프레임워크를 강제하거나 분석을 여러 애플리케이션에 통합하는 방법을 제한합니다. 이로 인해 팀 간에 마찰이 발생하고 전달 속도가 느려집니다.

이것이 초래하는 결과

팀은 사용하지 않는 프레임워크를 채택합니다.
애플리케이션은 SDK와 일치하도록 다시 작성됩니다.
분석은 제품 전반에서 다르게 작동합니다.

팀은 분석 계층에 맞게 제품을 조정하게 됩니다. 이로 인해 비효율성이 발생하고 새로운 기능이 더 빠르게 출시되지 않습니다.

귀사의 분석 SDK는 아키텍처를 제어하는 것이 아니라 아키텍처에 맞게 조정되어야 합니다. 여러 애플리케이션에서 작업하는 SaaS 팀의 경우 유연성은 분석을 확장할지 아니면 각 제품에 대해 다시 구축해야 할지 여부를 결정합니다.

AI가 분석 SDK를 변화시키는 방법

AI는 사용자가 데이터와 상호 작용하는 방식을 변화시킵니다. 보고서를 구축하는 대신 사용자는 데이터를 직접 쿼리하고, 통찰력을 생성하고, 심지어 생성할 수 있습니다. AI 기반 대시보드 단일 프롬프트에서 생성됩니다. 이를 통해 수동 작업을 줄이고 분석을 일상적인 워크플로에 더 가깝게 가져갈 수 있으며, 따라서 더 많은 팀이 채택하고 있습니다. AI 기반 분석 제품 내에 적용합니다.

AI enhanced analytics SDK

분석 SDK는 시각화를 넘어 더 많은 기능을 제공해야 합니다. 다음과 같은 사항을 처리해야 합니다.

데이터 모델에 매핑된 자연어 쿼리
사용자, 대시보드 및 데이터를 통해 컨텍스트 인식
모든 상호 작용에서 권한 시행
효율적인 처리로 제어 AI 토큰 비용 및 사용량

이러한 요구 사항은 실제 제약 조건을 야기합니다. AI는 데이터 경계 내에서 작동하고, 권한 모델을 따르고, 예측할 수 없이 비용을 증가시키지 않고 확장되어야 합니다.

그렇지 않으면 팀은 데이터 액세스 및 지출에 대한 통제력을 잃게 됩니다.

대부분의 플랫폼은 이러한 방식으로 구축되지 않았습니다. 기존 시스템 위에 AI 분석 기능을 추가하여 보안, 제어 및 비용 관리에 격차가 발생합니다.

분석 SDK에서 무엇을 확인해야 할까요?

결정은 분석 SDK를 사용할지 여부가 아니라 제품과 함께 확장할 수 있는 SDK를 선택하는 것입니다. 잘못된 선택은 제품이 성장함에 따라 제약 조건을 야기합니다.

다음 주요 요소를 고려하여 시작하십시오.

1. 구축 대 구매

분석 계층을 구축하면 완전한 제어권을 얻을 수 있지만, 최소 35만 달러의 투자, 7개월 이상의 구축 기간, 데이터 파이프라인, 전담 팀, 권한 및 프런트엔드 구성 요소에 대한 지속적인 투자가 필요합니다. 분석 SDK를 구매하면 개발 노력이 줄어들고 배송 속도가 빨라지지만, 솔루션이 아키텍처에 적합한 경우에만 가능합니다.

2. 기본 통합 (iFrame 없음)

SDK는 애플리케이션 내에서 기본 구성 요소를 제공해야 합니다. iFrame은 사용자 정의를 제한하고 분리된 환경을 만듭니다.

3. 다중 프레임워크 지원

React, Angular 및 Blazor와 같은 프레임워크에 대한 지원을 통해 팀은 기존 스택으로 작업하면서도 마찰 없이 작업할 수 있습니다.

4. 사용자 정의 및 제어

분석은 제품과 일치해야 합니다. SDK는 UI, 상호 작용 및 데이터 프레젠테이션에 대한 제어권을 제공해야 합니다. 화이트 라벨 분석은 SDK는 UI, 상호 작용 및 데이터 프레젠테이션에 대한 제어권을 제공해야 합니다.

5. 성능 및 확장성

분석은 속도가 느려지지 않도록 증가하는 데이터와 사용량을 처리해야 합니다. 확장 시 실시간 성능을 확인하십시오.

6. 보안 및 배포 유연성

데이터가 처리되는 위치(클라우드 및 온프레미스 환경 포함)를 제어해야 합니다. 온프레미스 분석 환경.

7. 데이터 연결

SDK는 다양한 데이터 소스에 연결하고 기존 시스템과 통합해야 합니다.

강력한 솔루션은 아키텍처에 적합하고, 팀을 지원하며, 제한을 도입하지 않고 제품과 함께 확장됩니다.

분석 SDK란 무엇입니까? 정의, 예제 및 올바른 SDK를 선택하는 방법

분석 SDK란 무엇입니까?