Adobe는 Magento 스토어용 기성 고객 앱을 제공하지 않으므로 모든 Magento 모바일 앱은 모바일 스토어 개선 및 중단, 웹 사이트-앱 변환기를 사용하여 앱 내부에 라이브 스토어 프론트 배치, 관리형 앱 서비스 고용, 자체 기본 화면으로 모바일 앱 확장 설치, Magento API에서 사용자 정의 기본 빌드 의뢰 등 5가지 경로 중 하나에서 제공됩니다.
두 번째로 매장을 얼마나 많이 건설해야 하는지와 Magento에서는 비용이 많이 들기 때문에 경로가 가장 다릅니다. 이 가이드에서는 다섯 가지를 비교하고 SiteTo.App이 잘못된 선택인 경우 전화 테스트 계획과 게시 메모를 제공합니다. 짧은 버전은 다음을 참조하세요. Magento에서 앱 페이지로.
Magento 스토어에 앱이 필요합니까?
Magento 및 Adobe Commerce 매장에는 유통업체, 직접 판매하는 제조업체, 부품 및 소모품 업체, 협상된 가격의 B2B 판매자 등 복잡한 카탈로그가 있는 경향이 있습니다. 많은 고객이 동일한 종류의 주문을 다시 하고 있으며, 해당 작업이 바로가기에 적합할 정도로 빈번할 때 앱이 그 자리를 차지하게 됩니다. 공급업체를 비교하기 전에 세 가지 질문을 해보세요.
- 고객은 매주 또는 매월 앱에서 무엇을 하게 될까요? 소모품을 재주문하고, 주문을 확인하고, SKU별로 부품을 조회하세요. 작업 이름을 지정할 수 없다면 빠른 모바일 사이트이면 충분합니다.
- 해당 작업이 모바일 매장에서 이미 작동하고 있나요? 매장에서 구축된 앱은 속도와 결제 기능을 상속받습니다.
- 알림이 구매자에게 도움이 될까요? 정기적으로 주문하는 품목에 대한 재입고 알림은 유용합니다. 주간 프로모션은 음소거하기 쉽습니다.
답변이 약하면 먼저 모바일 매장에 예산을 지출하세요.
Magento 모바일 앱을 얻는 5가지 방법은 무엇입니까?
| 노선 | 고객이 얻는 것 | 당신이 유지하는 것 | 결제 방법 | 매장에 제출하는 사람 |
|---|---|---|---|---|
| 1. 더 나은 모바일 매장 또는 PWA | 브라우저에서 선택적으로 설치할 수 있는 더 빠른 사이트 | 귀하의 매장 | 개발 시간 | 아무도; 스토어 등록정보가 없습니다 |
| 2. 웹사이트-앱 변환기(SiteTo.App) | 기본 셸에서 라이브 매장을 로드하는 귀하의 이름으로 된 앱 | 귀하의 매장 | 플랫폼당 1회: Android $29, iOS $79, 둘 다 $99 | 당신은 당신의 계정에서 |
| 3. 관리형 앱 서비스 | 팀이 설정, QA 및 제출을 처리하는 유사한 앱 | 귀하의 매장 | 월별 또는 연간 수수료 | 일반적으로 서비스는 |
| 4. 모바일 앱 확장 | 공급업체의 카탈로그, 장바구니, 결제 화면이 포함된 기본 앱 | 매장 전면, 커넥터 모듈 및 앱 디자인 | 라이선스 또는 구독과 맞춤화 | 귀하 또는 공급업체 |
| 5. 맞춤형 네이티브 빌드 | 무엇을 지정하든 | 매장 및 별도의 앱 코드베이스 | 프로젝트 비용 및 지속적인 유지 관리 | 귀하 또는 대행사 |
스토어 목록이 있는 모든 경로에는 개발자 계정도 필요합니다. Apple 개발자 프로그램은 연간 99달러이고 Google Play는 1회 25달러이며 Apple과 Google에 직접 지불됩니다.
1. 더 나은 모바일 매장 또는 PWA
때로는 정답이 앱이 아닌 경우도 있습니다. 기본 Luma 테마로 인해 휴대폰에서 매장 속도가 느려지는 경우 아이콘보다 가벼운 프런트 엔드가 고객에게 더 많은 역할을 합니다. 히베 테마 2025년 11월부터 무료 오픈 소스였으며 Adobe Commerce 판매자를 위해 Adobe는 이제 자체 문서를 문서화합니다. 상거래 매장, 기성품 드롭인 구성요소를 사용합니다. PWA 스튜디오 헤드리스 프로그레시브 웹 앱에서는 계속 사용할 수 있습니다.
PWA는 브라우저에서 홈 화면에 추가할 수 있지만 App Store에는 표시되지 않으며 iPhone의 웹 푸시는 고객이 그런 식으로 설치한 후에만 작동합니다. 우리의 가이드 PWA vs. 네이티브 vs. WebView 차이점을 다룹니다.
2. 웹사이트에서 앱으로 변환하는 변환기
변환기는 공개 매장 URL을 가져와 앱 내부에 배치합니다. SiteTo.App을 사용하면 앱이 라이브 웹사이트 주변의 기본 셸입니다. 아이콘과 시작 화면, 로고가 포함된 기본 헤더, 사이드 메뉴, 하단 탭, 뒤로 밀기, 새로 고침으로 당겨서 선택 사항, 자체 Firebase 프로젝트를 통한 푸시 알림(선택 사항) 등이 있습니다. 내부 페이지는 WebView에 로드된 Magento 페이지입니다.
Magento 서버에는 아무 것도 설치되지 않으며 API 자격 증명도 포함되지 않습니다. 고객 그룹 가격, 공유 카탈로그, 배송 규칙 및 모바일 사이트에서 렌더링되는 모든 확장 기능은 동일한 페이지이기 때문에 그대로 유지됩니다. 같은 이유로 앱은 모바일 매장만큼 훌륭하고 더 나을 수도 없습니다.
3. 관리형 앱 서비스
관리형 서비스는 페이지에 동일한 WebView 접근 방식을 사용하고 앱을 구성, 테스트, 제출 및 유지 관리하는 팀을 추가하며 종종 사용자 정의 기본 화면과 같은 추가 기능도 제공합니다. 해당 팀에 대해 반복적으로 비용을 지불합니다. 귀하의 비즈니스에 아무도 앱을 소유할 시간이 없다면 이는 합법적인 선택입니다. 우리는 그러한 서비스 중 하나를 비교합니다 SiteTo.App 대 MobiLoud.
4. Magento용 모바일 앱 확장
그만큼 Adobe 상거래 마켓플레이스 독립 공급업체는 Magento 2용 모바일 앱 확장을 판매합니다. 일반적인 디자인은 매장에 설치된 커넥터 모듈과 이를 통해 카탈로그, 카트 및 고객 데이터를 읽는 사전 구축된 기본 iOS 및 Android 앱입니다. 기본 제품 목록과 제품 페이지가 제공됩니다.
구매하기 전에 앱이 지원하는 사용자 정의, Magento 업그레이드를 통해 커넥터 호환성을 유지하는 사람, 목록을 보유한 개발자 계정이 무엇인지 물어보세요. 사용자 정의 옵션, B2B 기능 및 제3자 결제 방법에 대한 지원은 공급업체에 따라 다릅니다.
5. 맞춤형 네이티브 빌드
마젠토의 GraphQL API 헤드리스 매장과 모바일 클라이언트를 위해 설계되었으며 대행사는 그 위에 어떤 앱이든 구축할 수 있습니다. 이는 웹사이트가 제공할 수 없는 기능(창고 내 바코드 스캐닝, 현장 영업 담당자를 위한 오프라인 주문, Bluetooth 장치, AR 또는 백그라운드 처리)을 위한 유일한 경로입니다.
또한 Magento가 패치될 때마다 다시 테스트하는 두 번째 코드베이스이므로 유지 관리 및 빌드에 대한 예산이 필요합니다.
Magento에서 사용자 정의가 경로를 결정하는 이유는 무엇입니까?
Magento에서 중요한 로직은 PHP 모듈과 테마 템플릿에 있는 경우가 많습니다. 어떤 고객이 어떤 카탈로그를 볼 수 있는지, 고객 그룹이 지불하는 금액, 화물 견적 방법, 어떤 장바구니에 어떤 결제 방법이 표시되는지 등이 있습니다. 기본 앱은 템플릿을 읽을 수 없습니다. REST나 GraphQL을 통해 Magento에 요청하는데, 매장 전면을 변경하는 확장 프로그램이 항상 API를 통해 동일한 동작을 노출하는 것은 아닙니다. 각각의 격차는 결정이 됩니다. API 지원 구축에 비용을 지불하고, 앱과 사이트 간의 차이점을 수용하거나, 기능을 제외합니다.
경로 2와 3은 상점 전면을 재사용하여 질문을 피합니다. Route 4와 5는 한 번에 하나의 사용자 정의에 응답합니다. 견적을 요청하기 전에 고객이 로그인과 주문 확인 사이에 접촉하는 확장 프로그램과 사용자 정의 모듈을 나열하십시오. 짧은 목록은 기본 경로를 현실적으로 만듭니다. 긴 것은 당신이 가지고 있는 것을 재사용하자는 주장이다.
어느 Magento 매장에 적합한 경로는 무엇입니까?
| 당신의 상황 | 먼저 살펴보는 경로 |
|---|---|
| 모바일 매장이 느리거나 사용하기 불편합니다. | 매장 전면을 먼저 고치고 나서 결정하세요 |
| 귀하의 모바일 매장은 주문을 잘 받고 월별 앱 요금 없이 자신만의 목록을 원합니다. | 웹사이트에서 앱으로 변환하는 변환기 |
| B2B 구매자가 로그인하여 협상된 가격으로 재주문합니다. | 가격과 카탈로그가 서버 측에 유지되므로 변환기 |
| 앱을 원하지만 팀원 중 누구도 설정 및 저장 제출을 소유할 수 없습니다. | 관리형 앱 서비스 |
| 카탈로그와 결제가 표준에 가깝고 기본 제품 화면을 원합니다. | 모바일 앱 확장 |
| 스캔, 오프라인 주문 또는 기타 장치 기능이 필요합니다. | 커스텀 네이티브 빌드 |
| 세그먼트 또는 버려진 카트에 의해 트리거되는 푸시 캠페인을 원합니다. | 관리형 서비스, 해당 기능이 포함된 확장 또는 사용자 정의 빌드 |
Magento 매장에서 SiteTo.App이 잘못된 선택인 경우는 언제입니까?
- 모바일 매장이 느립니다. 앱이 동일한 페이지를 로드하므로 캐싱과 테마를 먼저 수정하세요.
- 웹 사이트에 존재하지 않는 화면을 원합니다. SiteTo.App은 페이지 주변에 기본 탐색 기능을 추가합니다. 재설계하지 않습니다.
- 타겟 또는 자동화된 푸시가 필요합니다. 알림은 대시보드에서 선택한 모든 사람에게 직접 전송됩니다. 아직 세그먼트나 일정이 없으며 Magento 이벤트가 이를 트리거할 수 없습니다.
- 구매자는 오프라인으로 작업하거나 바코드를 스캔합니다. 앱이 스토어를 로드하려면 연결이 필요하며, 스캔이나 블루투스와 같은 장치 기능을 추가하지 않습니다.
- 다른 사람이 매장 리뷰를 처리하기를 원합니다. 자신의 Apple 및 Google 계정에서 제출합니다.
WebView 앱 내에서 Magento 기능은 어떻게 작동하나요?
WebView는 Safari 또는 Chrome과 동일한 브라우저 엔진을 사용하므로 대부분의 Magento 매장은 휴대폰 브라우저에서와 마찬가지로 작동합니다. 예외는 예측 가능합니다.
Sessions. Adobe 설명서 고객 세션 수명 기본 쿠키 수명은 3,600초로 제공되며 세션 쿠키가 만료된 고객은 로그아웃됩니다. 앱 사용자는 로그인 상태를 유지하기를 기대하므로 이 기본값은 신중하게 결정할 가치가 있습니다. 설정은 스토어 > 구성 > 일반 > 웹 > 기본 쿠키 설정에 있습니다. 서버 세션은 별도의 시간 초과이며 Adobe에서는 이에 대한 관리 설정이 없으므로 개발자가 서버의 PHP 구성에서 이를 변경합니다. 세션이 길어지면 보안이 절충되므로 함께 동의하세요. 그만큼 영구 카트 고객이 기억하기를 선택하면 세션이 종료된 후에도 해당 장치에서 카트를 계속 사용할 수 있습니다.
캐시된 페이지. 전체 페이지 캐싱을 사용하면 Magento는 페이지가 로드된 후 브라우저의 로컬 저장소를 사용하여 미니 카트와 고객 이름을 채웁니다. 이는 WebView에서 작동하지만 장바구니에 추가한 후, 결제 후 및 로그아웃한 후에 장바구니 수를 확인하세요.
Payments. 게이트웨이의 카드 필드는 웹 양식입니다. 3-D 보안 문제, PayPal, 후불 서비스 제공업체 및 은행 리디렉션은 모두 귀하의 페이지를 떠나 주문 성공 페이지로 돌아와야 합니다. Apple Pay와 Google Pay는 기기와 내장된 브라우저가 노출하는 내용에 따라 달라집니다. 두 플랫폼 모두에서 모든 방법을 테스트합니다.
Sign-in. 이메일과 비밀번호는 신뢰할 수 있는 경로이며 매장 reCAPTCHA는 일반적으로 모바일 웹에서와 같이 로드됩니다. 구글의 OAuth 정책 내장된 웹 보기 내에서 로그인 화면을 허용하지 않으므로 소셜 로그인 확장 프로그램의 Google 버튼이 브라우저에서 작업하는 동안 앱에서 실패할 수 있습니다.
B2B 페이지. 회사 계정, 공유 카탈로그, 빠른 주문, 요청 목록 및 협상 가능한 견적 어도비 커머스 B2B 매장 페이지이므로 다른 페이지와 마찬가지로 앱에서 열립니다. 파일 작업은 테스트할 부분입니다. 빠른 주문에 CSV를 업로드하고 송장 PDF를 다운로드하는 것입니다.
매장 조회수. 앱은 하나의 URL을 엽니다. 매장 보기가 경로에 별도의 도메인이나 상점 코드를 사용하는 경우 앱이 시작되는 위치를 결정하고 매장 및 통화 전환기에 접근할 수 있도록 유지하세요.
Magento 스토어를 앱으로 어떻게 단계별로 테스트합니까?
가능하다면 iPhone과 Android 휴대폰, 그리고 각 고객 그룹에 대한 테스트 계정을 약 90분 정도 남겨두세요. 미리보기는 무료이며 카드가 필요하지 않으므로 결제하기 전에 전체 계획을 실행하세요.
1단계: 휴대전화로 매장 정보 확인
Safari와 휴대폰의 Chrome에서 프로덕션 스토어를 엽니다. 모바일 데이터로 홈페이지, 대형 카테고리, 상품 페이지를 로딩하세요. 여기서 느리거나 어색한 것은 앱에서도 동일합니다.
2단계: 미리보기 만들기
매장 주소를 붙여넣으세요. SiteTo.App. VPN 또는 IP 허용 목록 뒤에 있는 준비 사이트는 전화기에 로드되지 않으므로 프로덕션 URL을 사용하십시오. 앱 이름, 아이콘, 실행 화면을 설정한 다음 재방문 구매자가 수행하는 작업에 대한 탭을 구축하세요. 일반적인 세트는 홈, 검색, 장바구니, 주문 및 계정이며 B2B 매장에서는 홈을 빠른 주문으로 바꿀 수 있습니다. URL을 다시 작성하면 Magento의 기본 경로가 변경되므로 라이브 사이트에서 각 링크를 복사하세요. Magento의 검색 결과 URL에는 검색어가 필요하므로 검색 탭을 고급 검색 페이지나 검색창에 쉽게 접근할 수 있는 페이지로 지정하세요. 코드를 스캔하여 휴대폰에서 앱을 엽니다.
3단계: 로그인 및 세션 테스트
소매 계정으로 로그인하고 계정 대시보드를 엽니다. 미리보기를 완전히 닫았다가 다시 열어 여전히 로그인되어 있는지 확인하세요. 그런 다음 한 시간 이상 그대로 두고 다시 시도하세요. 이메일로 전송된 링크는 앱 외부에서 열리므로 비밀번호 재설정을 요청하세요. 제공하는 모든 소셜 로그인 버튼을 탭하세요.
4단계: 고객 그룹별 가격 및 카탈로그 테스트
도매 또는 회사 계정으로 로그인하고 3~4개의 제품을 웹사이트와 비교하여 가격 및 등급별 가격을 확인하세요. 공유 카탈로그를 사용하는 경우 해당 회사 카탈로그 외부의 제품이 숨겨져 있는지 확인하세요.
5단계: 제품 유형, 검색 및 필터 테스트
구성 가능한 제품, 번들 및 사용자 정의 옵션이 있는 모든 제품을 장바구니에 추가하세요. SKU로 검색하세요. 큰 카테고리에서는 여러 개의 계층화된 탐색 필터를 적용하고 제품을 연 다음 뒤로 스와이프하여 필터가 여전히 적용되어 있는지 확인합니다.
6단계: 실제 주문하기
3-D Secure를 실행하는 카드와 리디렉션하는 모든 방법을 포함하여 각 결제 방법으로 주문을 완료하세요. 나중에 환불하는 가치가 낮은 실제 주문이 가장 신뢰할 수 있는 테스트입니다. 앱 내부의 성공 페이지에 도달했는지 확인하세요. B2B의 경우 계정으로 주문하고 주문 내역에서 다시 주문할 수도 있습니다.
7단계: 중복 및 종료 확인
기본 헤더 아래에 표시되는 사이트 헤더와 탭을 덮고 있는 채팅 풍선 또는 쿠키 알림을 찾으세요. SiteTo.App은 앱에서만 실행되는 스크립트를 사용하여 사이트 요소를 숨길 수 있습니다. 외부 링크, PDF, 전화번호를 열고 돌아갈 길이 있는지 확인하세요.
페이지의 문제는 Magento에서 수정되었으며, 탐색 관련 문제는 SiteTo.App 설정에서 수정되었습니다. 의존하는 핸드오프가 실패하고 허용 가능한 폴백이 없으면 다른 경로를 선택하십시오. 당신은 알아내기 위해 아무것도 지출하지 않았습니다.
비용은 얼마이며, 앱 소유자는 누구인가요?
SiteTo.App은 플랫폼별로 한 번만 청구됩니다. Android의 경우 29달러, iOS의 경우 79달러, 두 가지를 함께 구매하면 99달러입니다. SiteTo.App 구독이 없습니다. 예를 들어 아이콘을 변경하기 위한 나중에 재구축은 별도로 인용됩니다. Magento의 일상적인 변경 사항은 다시 빌드할 필요가 없습니다. 그만큼 가격 페이지 세부정보가 있고, 비용 안내 더 넓은 시장을 비교합니다.
앱은 귀하의 개발자 계정에서 게시되므로 목록, 평가 및 리뷰는 귀하의 것입니다. 다른 경로의 경우 Magento 업그레이드에 보조를 맞추기 위한 작업을 포함하여 3년 동안의 총 기간을 각 공급업체에 문의하세요.
Magento 기반 앱을 App Store 및 Google Play에 어떻게 게시합니까?
그만큼 가이드 생성 및 게시 전체 순서를 살펴봅니다. 몇 가지 사항은 Magento 매장에만 적용됩니다.
iOS. 귀하의 빌드는 귀하의 Apple 계정으로 서명되어 TestFlight에 업로드되므로 Mac이나 Xcode가 필요하지 않습니다. 제출하기 전에 TestFlight 빌드에서 테스트 계획을 반복하십시오. 보다 Xcode 없이 웹사이트를 iOS 앱으로 변환.
Android. Google Play용 AAB를 받거나 직접 설치용 APK를 받습니다. Google은 새로운 개인 개발자 계정에 프로덕션 출시 전에 비공개 테스트를 실행하도록 요청하므로 이에 대한 시간을 허용하십시오.
검토자 액세스. 귀하의 카탈로그나 가격이 손님에게 숨겨져 있으면 리뷰어에게 로그인 벽이 표시됩니다. 적절한 그룹에서 데모 고객을 생성하고 해당 자격 증명을 리뷰 노트에 입력하세요.
계정 삭제. Apple에서는 계정 생성을 지원하는 앱이 앱 내에서 계정 삭제 기능을 제공하도록 요구합니다. 기본 Magento 고객 대시보드에는 삭제 옵션이 없으므로 요청 양식이나 확장 프로그램을 추가하고 계정 영역에서 연결하세요.
상품에 대한 지불. Magento 결제를 통해 구매한 실제 제품은 간단한 경우입니다. 다운로드 가능한 제품이나 디지털 구독을 판매하는 경우에는 App Store 심사 지침 첫 번째. SiteTo.App은 결제를 사용하며 Apple In-App 구매를 추가하지 않습니다.
승인 결정은 Apple과 Google이 내리며, 누구도 결과를 약속할 수 없습니다. Apple은 웹 사이트 이상의 추가 기능을 제공하지 않는 앱을 거부할 수 있습니다. 지침 4.2. 기본 탐색, 푸시 및 명확한 반복 작업이 모두 도움이 됩니다. 출판 가이드 리뷰를 더 자세히 다룹니다.
자주 묻는 질문
Magento에는 고객을 위한 자체 모바일 앱이 있나요?
아니요. Adobe는 API와 매장 도구를 제공하지만 매장에 미리 준비된 고객 앱은 제공하지 않습니다. 웹사이트-앱 변환기, 관리 서비스, 모바일 앱 확장 또는 사용자 정의 빌드를 통해 얻을 수 있습니다.
모듈을 설치하지 않고도 Magento 2 스토어를 앱으로 전환할 수 있나요?
예. SiteTo.App과 같은 웹사이트-앱 변환기는 공개 매장 URL에서 작동합니다. Magento 서버에는 아무것도 설치되지 않으며 REST 및 GraphQL API는 사용되지 않습니다. 모바일 앱 확장은 반대 접근 방식을 취하며 커넥터 모듈이 필요합니다.
Magento를 업그레이드하거나 테마를 변경할 때 새 빌드가 필요합니까?
아니요. 앱은 귀하의 매장이 제공하는 모든 것을 로드하므로 다음에 페이지가 로드될 때 업그레이드, 테마 변경 및 새로운 확장 기능이 나타납니다. URL이 이동된 경우 탭 링크를 업데이트하세요. 아이콘이나 시작 화면을 변경하려면 새 빌드가 필요할 수 있습니다.
다음 단계
고객이 로그인과 주문 확인 사이에 접촉하는 확장 프로그램 및 사용자 정의 모듈을 나열하십시오. 목록이 길고 모바일 매장에서 이미 주문을 잘 받고 있는 경우, 무료로 앱으로 미리보기 위의 7단계를 실행하세요. 그만큼 Magento에서 앱 페이지로 테스트하는 동안 옆에 보관할 수 있는 짧은 체크리스트가 있습니다.
