설명 파일은 업로드하는 피드 유형을 Google 시스템에 알리기 위해 업로드됩니다. 이렇게 하면 피드를 올바르게 확인하고 처리할 수 있습니다. 설명자 파일은 피드 콘텐츠 전에 업로드해야 하며 다음과 같은 이름 지정 요구사항을 따라야 합니다.
설명자 파일에는 .filesetdesc.json 파일 확장자를 사용해야 합니다.
각 설명자 파일 이름은 고유해야 하며 업로드 간에 재사용할 수 없습니다. 파일 이름에 생성 타임스탬프와 피드 이름을 포함하는 것이 좋습니다.
예: offers_1524606581.filesetdesc.json
각 설명자 파일에는 관련 피드 이름의 최신 피드에 있는 모든 데이터 파일이 나열되어야 합니다.
message FilesetDescriptor {
// The timestamp at which this feed was generated, in Unix time format
// (seconds since the epoch). (required)
int64 generation_timestamp = 1;
// Identifies the name of this feed. (required)
string name = 2;
// Paths (relative to the dropbox root) specifying data files included in this
// feed. (required)
repeated string data_file = 3;
}
설명자 파일을 업로드한 후에는 설명자 파일의 이름을 지정한 피드 구성 파일에 해당하는 피드 데이터 유형의 모든 피드 파일을 업로드합니다. 파일 이름과 경로 위치 (SFTP 서버 내 상대 경로)는 data_file 필드에 포함된 내용과 정확히 일치해야 합니다. 파일이 누락되거나 이름이 잘못 지정되었거나 다른 위치에 업로드된 경우 전체 피드가 처리되지 않습니다.
이러한 피드 데이터 파일의 콘텐츠는 설명어 파일에 지정된 피드의 관련 사양을 준수해야 합니다.
각 피드 파일 이름은 고유해야 하며 업로드 간에 재사용할 수 없습니다. 파일 이름에 생성 타임스탬프와 샤드 번호 (증분 ID)를 포함하는 것이 좋습니다.
예: offers_1524606581_1.json
피드 파일 크기 및 업로드 빈도
피드 파일 크기를 200MB 미만으로 유지합니다 (압축 후).
압축 해제된 각 데이터 파일의 크기는 2GB 미만이어야 합니다.
대부분의 통합은 단일 샤드만 사용하면 됩니다. 가능한 한 적은 수의 샤드를 사용해야 합니다. 피드당 최대 1,000개의 샤드가 있습니다.
하나의 샤드로 전송되는 개별 레코드는 이후 피드에서 동일한 샤드 번호로 전송하지 않아도 됩니다.
성능을 향상하려면 데이터를 샤드 간에 균등하게 분할하여 모든 샤드 파일의 크기를 비슷하게 만듭니다.
필요한 경우 gzip을 사용하여 피드를 압축합니다. 단, 개별 피드 샤드에 대해 이 작업을 실행합니다.
문제해결과 디버깅
파일 (디스크립터 및 피드 파일)을 업로드한 후 파트너 포털의 피드 기록 대시보드(문서)로 이동하여 (기록 > 피드로 이동) 피드 처리 진행 상황을 확인합니다.
'피드 이름' 열에서 설명자 파일에 입력한 name를 찾아 피드를 찾습니다.
피드가 처리되면 (상태가 Success 또는 Fail) 행을 클릭하여 오류 및 경고의 세부정보를 확인할 수 있습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-26(UTC)"],[],[],null,["# Using the Generic SFTP Server\n\nThe Generic feed SFTP server allows for multiple feed types to be uploaded to a\nsingle SFTP server per environment. This guide will walk through how to use the\nGeneric SFTP server and provide links to the appropriate guide for the respective\nfeed that you are planning to use.\n| **Warning:** This guide does **not** apply to the Merchants, Services, or Availability SFTP servers. It only applies to the Generic SFTP server.\n(Please refer to the [Exporting Feeds (end-to-end)](/actions-center/verticals/reservations/waitlists/integration-steps/export-feeds) or [Feeds (starter)](/actions-center/verticals/reservations/waitlists/integration-steps/feeds) section of the documentation).\n\n\u003cbr /\u003e\n\n| **Note:** You must be approved for each feed type that you will be uploading. If you upload a feed type that is not approved for your integration, the feed will not be processed. If you are unsure of which feed types apply to your integration, please reach out to your Actions Center contact.\n| **Warning:** You may need to reset your ssh key to enable uploads to the Generic feed SFTP server. To do so, please refer to [Partner Portal feed configuration](https://partnerdash.google.com/apps/reservewithgoogle/configuration/feeds?env=sandbox) ([documentation](/actions-center/verticals/reservations/waitlists/partner-portal/testing/feeds)).\n\nThe Generic SFTP server relies on there being two separate uploads:\n\n1. **Descriptor file:** describes what feed type you will be uploading\n2. **Feed file(s):** the content of the actual feed\n\n| **Note:** If you make an upload to the generic SFTP server and do not see any corresponding entry in the Partner Portal that may mean that your descriptor file was not uploaded or has an incorrect file name. For help debugging this issue please reach out to your Actions Center contact.\n\n### Structuring the descriptor field\n\nThe descriptor file is uploaded to inform our system of what feed type you\nare uploading. This allows us to validate and process the feed correctly. The\ndescriptor file should be uploaded before the feed contents and must follow\nthese naming requirements:\n\n- You must use the `.filesetdesc.json` file extension for the descriptor file.\n- Each descriptor filename must be unique and can't be re-used across uploads. We recommend including the generation timestamp and feed name in the filename.\n - Example: offers_1524606581.filesetdesc.json\n- Each descriptor file must list all data files in the latest feed for the relevant feed name.\n\n```scdoc\nmessage FilesetDescriptor {\n // The timestamp at which this feed was generated, in Unix time format\n // (seconds since the epoch). (required)\n int64 generation_timestamp = 1;\n\n // Identifies the name of this feed. (required)\n string name = 2;\n\n // Paths (relative to the dropbox root) specifying data files included in this\n // feed. (required)\n repeated string data_file = 3;\n}\n```\n\nPossible values for the `name` field include:\n\nAn example JSON descriptor file for an offers feed with two shards is\navailable below: \n\n```scdoc\n{\n \"generation_timestamp\": 1524606581,\n \"name\": \"promote.offer\",\n \"data_file\": [\n \"offers_1524606581_1.json\",\n \"offers_1524606581_2.json\"\n ]\n}\n```\n\n### Structuring the feed content\n\nAfter uploading the descriptor file, you will then upload all of the feed files\nfor the feed data type corresponding to the feed configuration file named by\nyour descriptor file. The file names and path locations (relative within the\nSFTP server) must exactly match what was included within the\n`data_file` field. If any file is missing, improperly named, or\nuploaded to a different location then the entire feed will not be\nprocessed.\n\nThe contents of these feed data files must conform to the relevant spec of\nthe feed that was specified in the descriptor file.\n\n\nEach feed file filename must be unique and cannot be re-used across uploads. We recommend\nincluding the generation timestamp and the shard number (incremental id) in the filename.\n\n- Example: offers_1524606581_1.json\n\n### Feed file sizes and upload frequency\n\n- Keep feed file size below 200 MB (after compression).\n- Each decompressed data file size should be less than 2 GB.\n- Most integrations will only need to use a single shard. You should use as few shards as possible. There is a maximum of 1000 shards per feed.\n- Individual records sent in one shard don't need to be sent in the same shard number in future feeds.\n- For better performance, split data evenly among the shards, to make all the shard files similar in size.\n- If necessary, use gzip to compress feeds. However, do so for each individual feed shard.\n\n### Troubleshooting and debugging\n\n\nAfter uploading your files (descriptor and feed files) head to the\n[Feed History dashboard](https://partnerdash.google.com/apps/reservewithgoogle/dashboards/feeds?env=sandbox)\n([documentation](/actions-center/verticals/reservations/waitlists/partner-portal/dashboards/feeds-dashboard))\non the Partner Portal (navigate to **History \\\u003e Feeds**) to follow the progress of your feed ingestion.\n\n\nLook for the `name` you have input in the descriptor file in the \"Feed name\" column to find your feed.\n\n\nOnce the feed is ingested (status is `Success` or `Fail`) you can click on\nits row to see the details of the errors and warnings."]]
