Problem Statement related FAQs
Q1: What is the significance of an open-source map in the context of developing systems for Geographic and Location-based use cases?
Ans: Fundamentally, open source maps, such as S3 indexes used by Uber, offer a cost-effective alternative to expensive API-based map services when developing systems for Geographic and Location-based use cases. They can be embedded into applications as either an SDK or an API-based service, providing a cost-effective solution with greater potential for scalability.
Q2: Can you clarify the role of biometrics in the context you mentioned, especially concerning both the violent makeup artist and network participants?
A: Biometrics play a significant role in the mentioned context, involving both violent makeup artists and network participants. It appears that there is a need for a comprehensive policy, potentially related to safety or security, to address the overall aspect of this situation but can make sure of car to NBC dot 1G.
Q3: How do we ensure that both buyers and sellers adhere to API contracts within the network?
A: The assurance of adherence to API contracts involves two key aspects. Firstly, network participants, including buyers and sellers, must comply with the policies outlined by ONDC, which are accessible on our website. Secondly, every transaction on the network is governed by a transaction-level contract. This combination of network policies and transaction-level contracts acts as the framework controlling the rules of engagement. In the event of non-compliance, buyers can seamlessly issue notifications or deny processing of payloads received from other participants, ensuring adherence to the established protocol.
Q4: Can any third-party provider independently develop both a seller and a buyer app and register them on the ONDC Network, or does ONDC control the UI of these apps?
A: Not. The core concept of ONDC is to facilitate platforms in communicating with each other. Buyer and seller app providers have the freedom to create their UI and UX for both buyer and seller apps. ONDC offers a reference buyer app in the Sahara which serves as a benchmark or reference point for them to develop their applications.
Q5: How do large e-commerce giants differentiate themselves within the ONDC integrated ecosystem, and is there a classification between large and small e-commerce providers within the ONDC network?**
A: Within the ONDC integrated ecosystem, there is no classification between large and small e-commerce providers. The concept of ONDC is inclusive, allowing all platforms to add value independently. Large players, while offering specialised products and services, may choose to join ONDC, complying with its protocols to enhance buyer choices and provide sellers with better market access, contributing to the expansion of their avenues.
Q6: What is the current status of the store digitization process, and is it primarily manual? How is catalogue digitization being handled, especially in the context of the hackathon problem statement?
A: The store digitalization process involves various methods, with catalogue digitization being a notable challenge addressed in the hackathon. Currently, many seller apps employ diverse approaches, including the use of AI for catalogue creation. Sellers are assisted by these apps, providing tools and models to digitise their catalogues, making the process more efficient.
Q7: If a seller goes live on OTC using a seller app, will they be visible to the buyer apps?
A: Yes, if UPS today discloses sorting and filtering criteria. If they pass a sorting and
filter in criteria, which is public, they should be visible.
Q8: Can component manufacturers in the ONDC ecosystem serve clients outside India, and how can interested parties join the network?
A: Yes, component manufacturers in the ONDC ecosystem can indeed engage with clients outside India, as demonstrated by a proof of concept transaction between Singapore and India. To join the network, interested parties, whether directly or as sellers, can attend regular sessions, typically held every Thursday. Detailed information and mechanisms for joining can be found on the ONDC website, including a strategy paper and other valuable resources. While addressing questions related to joining the network, the focus here will be on addressing hackathon-related queries to benefit the entire community.
Q8: How does the real-time tracking process in ONDC differ from platforms like Swiggy, which offer real-time tracking for delivery partners, especially in the context of grocery and food delivery?
A: Currently, the tracking in ONDC is text-based and doesn't provide real-time tracking like Swiggy. However, work is already underway, leveraging the learning involving the network and resources. Future developments are expected to introduce features, including real-time tracking, enhancing the overall experience.
Q9: When building a solution for the hackathon, particularly focusing on the Seller side and digitalizing the catalogue, should the solution cater to all ONDC network participants or be platform-specific?
A: Fundamentally, there's no confinement to a narrow scope. Whether working on a solution for a specific platform or aiming to serve all ONDC network participants, as long as the theme of open network and interoperability is maintained, participants are encouraged to create solutions based on their innovative ideas.
Q10: What is the submission format for the project in terms of architecture and resources, and what is expected regarding the use of databases and APIs?
A: The submission should include the source code and front-end code to demonstrate the solution's functionality and scalability. Participants are expected to use datasets available online based on the problem statement. While ONDC will not provide specific data, publicly available sources are recommended. Test cases and data should be provided with the solution for testing purposes.
Q11: Can third-party APIs or products be used for integrating into our system for respective solutions?
A: Yes, using third-party APIs or products is permissible, as long as the solution can be tested, and there are no conflicts. Participants need to ensure there is no conflict, especially concerning proprietary elements. The responsibility for the solution lies with the participants, and ONDC doesn't interfere in the business practices of the entities involved.
Q12: Are there any guidelines for displaying filters on search results for buyers, or is it on a first-come-first-serve basis?
A: Filtering and sorting criteria are determined by the buyer apps, and the only requirement is for them to declare their filtering criteria, ensuring unbiased results. The criteria declaration is available on the ONDC website, with links provided in the resource section, specifying sorting and filtering criteria for each.
Q13: What documentation or requirements are necessary for the onboarding process of sellers on the Seller App and ONDC, including Kiara KYC?
A: Detailed information on the documentation and requirements for onboarding sellers is available on the ONDC website and the respective seller applications. For specific questions, participants are encouraged to join the community call, keeping the focus on hackathon-related queries and discussions. The emphasis is on addressing hackathon-related concerns rather than becoming a general ONDC community session.
Q14: If I have developed a solution and built an app, how can I test its compatibility with the ONDC network or utilise your industry protocol?
A: To test your solution, you can find mock APIs on GitHub or create your mocks. ONDC provides a reference app with various interfaces, and you can create a Postman collection for demo purposes. Multiple APIs are available for different sectors like glossary and food or financial services. The resource section will be updated with information and links to reference apps for testing compatibility with the ONDC network.
Q15: Can I start preparing solutions for more than one problem statement?
A: Yes. But please register particularly for how many number of problems that you are
registering. for your trying to attend so that we have a count of the numbers.
Q15: Is there a centralised database controlled by ONDC containing all seller and buyer information that can be accessed for data retrieval?
A: No, ONDC does not control any centralised database. However, information on seller and buyer apps is available on the ONDC website. Network participant details can be accessed through the provided link on the website. Refer to the shared link for all the required information.
Q16: I'm considering building a light Progressive Web App to connect buyers with component manufacturers, especially for the problem statement related to components manufacturers. If I have doubts or need assistance, are there additional sessions or platforms where I can reach out to someone from ONDC for guidance?
A: Yes, besides the Community Call, the schedule for future masterclasses will be published, providing opportunities to address specific questions related to problem statements. Attendees can check the schedule and participate in these sessions to seek guidance and clarification for their projects.
Q17: Regarding the selection criteria for problem statements, particularly in terms of the scope and scalability of the solution, how will shortlisting and selection take place among participants?
A: The shortlisting process involves both technical and business evaluations, considering factors like scalability. The first stage of shortlisting will lead to the selection of candidates for the demo day. During demo day, participants will present their solutions, and a fair and transparent process will be followed for further evaluation. If there are multiple solutions with similar execution levels, they will all be accommodated, and the final selection will be made based on the discussions and demonstrations during demo day.
Q18: Regarding the selection criteria for problem statements, particularly in terms of the scope and scalability of the solution, how will shortlisting and selection take place among participants?
A: The shortlisting process involves both technical and business evaluations, considering factors like scalability. The first stage of shortlisting will lead to the selection of candidates for the demo day. During demo day, participants will present their solutions, and a fair and transparent process will be followed for further evaluation. If there are multiple solutions with similar execution levels, they will all be accommodated, and the final selection will be made based on the discussions and demonstrations during demo day. Additionally, participants are encouraged to explore product-market fit by identifying seller apps online and proposing how their solution can integrate and customise based on specific seller app requirements.
Q19: For the solution submission on the Hackathon website, only asks for the approach of the solution. Should we provide a certain link to our demo, or is a description sufficient?
A: The submission requires a demo of the solution, including the source code, front-end application, and test cases. It is not just a description; the demo should be accessible for evaluation. The source code repositories must be made public for evaluators to review. The submission details and expectations are problem-specific, so participants should ensure clarity on the requirements for the particular problem they are addressing.
Q20: If we have developed solutions for multiple problem statements, can we apply for each one separately? For the InVent initiative, where they are looking more into the business side rather than the code, how should we proceed?
A: Yes, you can apply for multiple problem statements separately. Once you register and choose a specific problem statement, follow the submission format provided on the website for that particular problem. For the InVent initiative, the expectations and guidelines for submission will be specified in the registration and submission process. Ensure you review and adhere to the requirements for each problem statement you are applying to.
Q1: When building a pricing optimization engine for the petrochemical industry, how can real-time pricing be determined, considering factors like crude oil prices and supply chain disruptions?
A: To determine real-time pricing for the petrochemical industry, the pricing optimization engine should take into account a set of inputs, such as global supply and potential disruptions in the supply chain. Factors like crude oil prices, local market conditions, and reference data points for various products should be considered. The engine should be designed to handle dynamic pricing, considering factors specific to each user, SKU, and packing size. Additionally, incorporating a validity period for prices can enhance the accuracy of the pricing optimization.
Q2: In the context of digitising catalogues, what are the pain points to consider, especially in fine-tuning multimodal models like LAVA?
A: The pain points in digitising catalogues include handling imperfect inputs such as unclear images or voice data, implementing error correction and detection mechanisms, and addressing challenges faced by smaller sellers with limited technology. Additionally, the challenge involves creating a multimodal solution that seamlessly digitises catalogues, capturing various attributes like SKU ID, price, manufacturer, brand, colour, etc. In terms of fine-tuning multimodal models like LAVA, the process involves creating a custom dataset closely matching the problem statement, curating and tweaking data if necessary, and then fine-tuning the existing model on the custom dataset. Fine-tuning can be facilitated by freezing most layers of the model and modifying the last few layers based on the specific problem statement.
Q3: For the problem statement of digitising catalogues, is there a novel aspect expected from solutions, especially considering existing solutions based on voice chat?
A: A perfect solution for digitising catalogues may involve a multimodal approach that supports various input interfaces. The challenge lies in capturing information comprehensively, including SKU ID, price, manufacturer, brand, colour, etc., and ensuring seamless digitization for smaller sellers who may lack technology. The novel aspect could be creating a solution that efficiently maps different types of inputs to a dataset, providing a reference data point for price determination. The goal is to enable even the smallest sellers across districts to digitise their catalogues easily.
Q4: In building a pricing optimization engine for the petrochemical industry, how can real-time pricing be determined, considering factors like crude oil prices and supply chain disruptions?
A: Real-time pricing for the petrochemical industry's pricing optimization engine can be determined by considering inputs such as global supply, potential disruptions in the supply chain, and specific factors like crude oil prices. The engine should be designed to handle dynamic pricing, considering each user's requirements, SKU, and packing size, and ensuring that the pricing is valid within a specified period. The challenge is to create a system that provides reference data points for prices, considering the dynamic nature of the market.
Q5: In the context of the catalogue digitization problem statement, once the catalogue is digitised, how can sellers export the catalogue to the ONDC seller network or aggregator?
A: Sellers can commonly export their digitised catalogues to the ONDC seller network or aggregator using bulk data in Excel format. Excel interfaces are widely used to import data into seller aggregators, allowing them to map the catalogue information to the required format on the ONDC platform. This method facilitates the seamless integration of digitised catalogues into the ONDC ecosystem.
Q6: In the ONDC framework, specifically considering the beacon protocol, are participants expected to address all layers, including the seller app, or should the focus be on creating solutions with clean abstractions that can be easily integrated into any app?
A: Participants are expected to focus on creating solutions with clean abstractions that can be easily integrated into any app within the ONDC framework. The backend protocol, including layers such as the seller app, is managed by ONDC. The goal is to provide solutions that abstract complexities and can be smoothly integrated by any participant into the broader ONDC ecosystem, without requiring direct involvement in the backend protocol layers.
Q7: For smaller shops that may face challenges in creating digital catalogues, is there any out-of-the-box incentive from ONDC to encourage them to adopt digital catalogues?
A: ONDC aims to enable small sellers to come online and enhance their visibility on the network through solutions that facilitate inventory management and product availability. While ONDC does not provide a direct incentive, the goal is to explore solutions that empower small sellers to transition online. The business aspect, including incentives or support mechanisms, will be addressed separately.
Q8: Regarding the digitization of catalogues, small sellers dealing with lower-value products may find it challenging to onboard their products due to the associated hassle. Will there be any assistance or interest in mitigating this hassle for small sellers?
A: The business aspect, including addressing the challenges faced by small sellers in onboarding lower-value products into digital catalogues, will be covered separately. The focus is on finding solutions that enhance inclusion and empower small sellers to transition online, with considerations for business incentives and support mechanisms.
Q9: In the context of order and inventory management for groceries, there's a requirement for the solution to work in low or even no internet connectivity scenarios. How can the exact count of inventory be managed when the stock is reduced without internet access?
A: The expectation is that the solution should be designed to function in various connectivity scenarios, including low internet connectivity. In cases where a seller has no internet connectivity, participating in digital commerce may need to be addressed separately. For intermittent or low connectivity, the solution should adapt to bandwidth constraints, ensuring a low footprint. The challenge of managing inventory count when the stock is reduced without internet access can be approached by exploring offline modes, periodic sync mechanisms, or local storage capabilities to capture and reconcile inventory changes during periods of connectivity. Detailed considerations would depend on the specific features and functionalities of the proposed solution.
Q10: Considering a scenario where a seller has stock available before going online, how can the inventory count be managed if there is no internet connectivity at that time?
A: If a seller has stock available before going online and faces no internet connectivity, managing the inventory count becomes a challenge. The solution needs to incorporate offline capabilities, allowing the seller to capture and track changes to the inventory locally. This could involve offline modes where the system records transactions and updates the inventory when connectivity is restored. Alternatively, periodic synchronisation mechanisms may be implemented to reconcile inventory changes once internet access is available. The design should focus on ensuring accurate and reliable inventory management, even in offline scenarios, to facilitate seamless digital commerce participation.
Q11: Can you provide information about the UAT (User Acceptance Testing) environment, specifically if there's access to data through APIs? Additionally, could you explain the authorization process and the client secret that needs to be used?
A: For details regarding the UAT environment, API access, authorization process, and client secret usage, please reach out to the ondc team directly via the email provided. They can provide specific information and guidance related to testing environments, API access, and any authentication requirements. It's recommended to contact them for accurate and up-to-date details on these technical aspects.
Q12: What pain points is ONDC aiming to address in the onboarding process for sellers, considering that other platforms like Amazon have a six to seven-step onboarding process?
A: The pain points in onboarding sellers for ONDC revolve around ensuring a smooth transition for sellers who are not yet engaged in digital commerce. Key challenges include the need for a digital catalogue, real-time inventory and price updates, and efficient order fulfilment processes. ONDC is seeking solutions that simplify onboarding for sellers, potentially through innovative approaches like mobile apps acting as order management tools. The focus is on making the onboarding process accessible and user-friendly, especially for sellers unfamiliar with digital commerce practices. The goal is to address the unique needs of small sellers and facilitate their seamless participation in the ONDC network.
Q13: Regarding the logistics theme with the use of open-source maps, what is the specific goal of this problem statement? Since open-source solutions are available, what innovation is ONDC looking for in this context?
A: The goal of the logistics problem statement is to enhance the accuracy and user interface of solutions using open-source maps, particularly in reverse geocoding. While open-source solutions exist, they may have limitations in terms of accuracy and user experience. ONDC aims to innovate in this space by seeking solutions that are open source, but at the same time, provide a level of accuracy and user experience comparable to commercial solutions. The focus is on making these solutions affordable and accessible, especially for smaller participants, aligning with the goal of driving inclusion in digital commerce. The innovation sought is in creating scalable solutions that can cater to a diverse range of sellers and marketplaces.
Q14: Given that some existing solutions are available, what kind of innovation is ONDC looking for in the logistics domain?
A: ONDC is looking for innovations that address the diverse needs and technical capabilities of different sellers and marketplaces, enabling inclusion for all scales of operations. The emphasis is on finding solutions that are not only effective but also scalable to reach the smallest sellers possible. While solutions may exist, the challenge lies in creating an innovative solution capable of catering to the varying requirements of different participants in the digital commerce ecosystem.
Q15: In price optimization, are there specific sectors we are required to focus on, or can we choose any sector?
A: There is no restriction on the sector for price optimization. ONDC spans various categories and domains, including grocery, electronics, fashion, mobility, and upcoming sectors like financial services, insurance, and credit. The focus in price optimization is particularly on sectors dealing with perishable items or services, where prices are time-sensitive and tend to fluctuate significantly.
Q16: Is it mandatory to use Vertex AI for producing ML models, or can we use our machines for the task?
A: The solution needs to be deployed in Google Cloud, and while you can use open-source APIs for certain subproblems, the final deployment of the solution should be on Google Cloud. Vertex AI provides a comprehensive solution for ML tasks in Google Cloud, simplifying the process. While using open-source APIs for subproblems is an option, deploying the final solution should be done in Google Cloud.
Q1: Regarding the Optimal Anderson Matrix problem, can the data received from merchants be stored only as a matrix, or is it possible to store it alternatively as graphs or other data structures for more convenient retrieval?
A: The data, although initially in matrix form, does not need to be stored exclusively as a matrix. You have the flexibility to store it in any form that is most convenient and efficient for retrieval. The key requirement is optimal storage and retrieval in real-time. Feel free to explore alternative storage mechanisms, such as graphs or other data structures, to determine what suits the problem best.
Q2: Does ONDC store the catalogue data within itself, or is it limited to storing transactional data locally? What is the mechanism behind catalogue data storage within ONDC?
A: ONDC primarily facilitates transactions between two parties and doesn't store catalogue data within itself. However, there is an initiative called "Catalog as a Service" that aims to enable participants to create a catalogue by taking data feeds from a centralised catalogue service. The focus is on supporting statutory requirements, providing participants with essential details for branded products, and improving catalogue quality for better discoverability on the buyer app.
Q3: What does the term "incremental catalogue refresh" mean within the ONDC ecosystem, and how does it work?
A: Incremental catalogue refresh refers to the process of updating catalogue information based on changes since the last full catalogue pull. In a hyper-local context, where catalogues are displayed store-wise, buyer apps initially request a full catalogue pull, storing basic details. Subsequent incremental updates include changes in inventory, prices, quantities, and other relevant data. ONDC doesn't store this data but facilitates the transfer and synchronisation of information to keep buyer apps up-to-date.
Q4: Does ONDC currently support the Indic language, allowing users to change the language to their native language or any language of their preference? If so, how does the indic language support work, and what is its specific focus within the ONDC ecosystem?
A: ONDC 's indic language support primarily focuses on enabling the ecosystem rather than the ONDC website itself. It facilitates the use of regional languages in queries and interactions within the ecosystem. For example, participants may have catalogues stored in one language, and users might want to query these catalogues using a different language. Indic language support ensures that the ecosystem can handle queries, searches, and interactions in diverse languages, making it more accessible and user-friendly for participants involved in real transactions within the ONDC ecosystem.
Q5: If a user searches for catalogues in a regional language, how does ONDC ensure that the query is processed, and relevant information is retrieved, even if the catalogues are stored in a different language?
A: The indic language support in ONDC allows users to search for catalogues in their preferred regional language. The system is designed to understand and process queries in diverse languages, even if the underlying catalogues are stored in a different language. This ensures that users can interact with the ONDC ecosystem in the language of their choice, improving the accessibility and usability of the platform for participants involved in real transactions.
Q6: Can we use third-party APIs or open-source APIs, such as those for GPS or LLMs, when developing individual components of our solution for the ONDC challenge?
A: Yes, you are free to use third-party APIs or open-source APIs for building individual components of your solution. During the development phase, you can leverage any services or APIs that suit your needs. It's important to consider licensing requirements, especially for proprietary APIs. However, the final product solution must be deployed on Google Cloud as per the ONDC challenge guidelines. Ensure that any third-party APIs you use comply with licensing terms and are suitable for enterprise purposes.
Q7: Are there any restrictions on using specific third-party APIs, especially those coming from Stanford or other sources, and how should one navigate licensing requirements when incorporating such APIs into the solution?
A: While you are free to use third-party APIs, including those from sources like Stanford, it's crucial to check and comply with licensing requirements. Some APIs may have restrictions on usage for enterprise purposes or specific licensing conditions. Before incorporating any third-party APIs, carefully review the licensing terms and conditions to ensure compliance. If the API is open-source, confirm that it aligns with the goals of the ONDC challenge and is permissible for use in your solution.
Q8: How can the buyer app APIs on ONDC be accessed and utilised for catalogue retrieval and filtering?
A: The buyer app APIs on ONDC are primarily designed for data exchange. Catalogue retrieval is typically done in bulk, where the buyer apps pull the catalogues, clean up the data, and create an immersive user experience for buyers. Filters, such as searching for specific items within a price range or with certain characteristics, are implemented on the buyer app's side. The data exchange APIs support various types of catalogues, including block tables and specific items that sellers can pull from their end. While the APIs provide the necessary data, the implementation of filters for user experience is handled on the buyer app.
Q9: Are specific filters, such as searching for products within a certain price range or with specific attributes like colour, available through ONDC APIs for buyers to implement in their apps?
A: The specific filters for user experience, such as searching for products within a certain price range or with specific attributes like colour, are not directly provided through ONDC APIs. The APIs focus on data exchange, allowing buyers to pull catalogues and handle the implementation of filters on their apps. Buyers can use the data provided by ONDC APIs to create a visually appealing and user-friendly interface with the desired filtering options.
Q10: Can sellers pull specific items or utilise filters for catalogue retrieval from the ONDC APIs, and how is this functionality integrated into the overall buyer experience?
A: Sellers can pull specific items or catalogues using ONDC APIs, including block tables and other types of catalogues. However, the uptake of specific item pulls has been limited. The filters and user experience, including features like searching for specific items based on certain criteria, are primarily implemented on the buyer app's side. Sellers can leverage the available APIs to exchange catalogue data with buyers, who, in turn, create a rich user experience with filters and visual elements for their app users.
Q11: What is the expected interface for the solution to the optimal storage and retrieval in an M-crosses spazmatics problem?
A: The solution should provide a clean abstraction that allows users to feed data in various formats. The input could be in the form of a matrix, a two-dimensional array, or even a graph. The key is to support multiple input data formats. The solution should also offer a response in a standard format, making it easy for anyone to use. The emphasis is on creating a standard and easily usable interface for the problem.
Q12: Can the solution interface accept inputs in various formats and provide real-time responses?
A: Yes, the solution should be able to handle inputs in various formats, but it is crucial to maintain a standard format for ease of use. The goal is to support multiple data input interfaces, and the solution should be capable of providing real-time responses based on the input data.
Q13: What could be a suitable input format for the optimal storage and retrieval solution, and what is the expected output?
A: While the exact input format is not specified, it is suggested that a standard format, such as a CSV file or a two-dimensional array, could be suitable. The solution aims to search for merchants based on PIN codes and deliver a response that includes the set of PIN codes serviced by each merchant. The goal is to efficiently retrieve information about merchants based on PIN codes and provide a meaningful output.
Q14: Is the sparse matrix data provided by the seller, or is it stored in a standalone database on a server accessible by both sellers and buyers?
A: The exact source of the sparse matrix data is not explicitly specified in the problem statement. However, it is clarified that the problem is primarily for the buyer app, which performs serviceability checks in near real-time when displaying catalogues. Whether the data is stored by sellers or in a standalone database, the focus is on creating an interface for efficient storage and retrieval, and the buyer app is the primary consumer of this information.
Q15: Does the storage location of the sparse matrix data impact the implementation of the solution?
A: The storage location of the sparse matrix data is not a critical factor for the implementation of the solution. The emphasis is on developing an interface for efficient storage and retrieval of data, and whether the data is with sellers, in a database, or elsewhere is not a concern for the solution. The key is to create a standard interface for the problem.
Q16: What is the primary role of the buyer app in relation to the sparse matrix data?
A: The buyer app performs serviceability checks in near real-time when displaying catalogues. It relies on the sparse matrix data to determine the serviceability of products and merchants. The focus is on creating an interface that enables the buyer app to efficiently retrieve and utilise this data for providing a seamless user experience.
Q1: If a startup is operating in a domain similar to a company in which Antler has already invested, will Antler still consider investing in the new startup as part of Bharat?
A: Antler follows a specific policy in such cases. If they have already invested in a company (let's call it Company A) and another startup (Company B) is building something very similar, Antler has a cooling-off period of six months. During this period, they will not invest in anything similar to what Company A is doing. However, after the cooling-off period, Antler may consider investing in Company B or similar ventures. This policy ensures a fair approach to investing in startups in similar domains.
Q2: What steps is ONDC taking to address the issue of high commissions from merchants, which can potentially lead to higher prices for customers compared to other platforms?
A:Merchants on ONDC may charge high commissions, potentially resulting in higher prices for customers. The response acknowledged the significance of providing competitive pricing to customers, emphasising a commitment to solving problems for both customers and entrepreneurs. Although no specific solution or action was outlined in the provided content, the response indicated an openness to addressing the concern and a commitment to working on improvements.
Q3: How does the Data as a Service (DaaS) model position itself on ONDC, especially considering the decentralised nature of the platform?
A:Data as a Service (DaaS) model would position itself on ONDC, comparing it to centralised models like Amazon and Flipkart, given ONDC's decentralised nature. The challenge of data sharing, even in centralised models, was emphasised, stating that extracting and sharing data across teams can be difficult. In the ONDC decentralised approach, where data is distributed across multiple participants, the challenge becomes more complex. The ONDC model, a technical service provider (DSP) might register on the network, focusing on a specific area such as a buyer-side DSP or a seller-side DSP. The DSP would provide services related to the kind of data, analytics, or recommendations it specialises in. The model involves collaboration with multiple buyer apps, integrating services, and running recommendations in a decentralised manner for various buyers. This approach allows DSPs to offer specific services to the participants on the ONDC network.
Q4: Is there scope beyond Agri and Rural in ONDC, particularly in the fintech domain?
A:The ONDC team encourages participants to explore various domains and problem areas within the ONDC ecosystem, stating that the problem statements, including those related to Agri and Rural, are not exhaustive. They emphasised that ONDC is a versatile platform, and building solutions for Agri, considered a challenging consumer set in India, can serve as a strong foundation for addressing other sectors. Additionally, they encouraged participants to reach out to the ONDC community and apply for programs like The Residency for further collaboration and support in exploring fintech solutions within the ONDC framework. The team expressed openness to diverse projects aligned with the broader vision of ONDC.
Q5: What level of data should be expected from the NPS or sellers operating on ONDC for the "Data as a Service" problem statement?
A: The "Data as a Service" problem statement focuses on facilitating secure, private, and trustable data exchange between various participants (NPS, sellers, etc.) on the ONDC network. It emphasises that the custodian of the ONDC protocol does not have visibility into the data, and the goal is not to provide direct access to data but to enable participants to set up systems for secure data exchange. The analogy of the account aggregator framework was used to explain the concept, highlighting that data analytics can be performed on top of the data received by the respective buyer or seller apps without directly accessing the underlying protocol data. The clarity on the level of data accessible for analytics purposes would be provided later, and the ONDC community encouraged participants to engage for further discussions and insights.
Q6: What types of information are available on ONDC for data exchange, particularly concerning observability?
A: ONDC will provide details on the types of information available for observability later. However, the key emphasis is on the concept of "Data as a Service," where the goal is to build a framework or technology for secure data exchange between entities without direct access to the data. The analogy draws attention to the account aggregator framework, highlighting the importance of privacy and security in facilitating data exchange between participants on the ONDC network. ONDC encourages participants to await further details on the information accessible for analytics purposes and engage with the community for additional insights.
Q7: If a fintech startup has already raised funds in an initial round, are they eligible to participate in the program, and how does the equity allocation work for such startups?
A: Yes, fintech startups that have already raised funds in an initial round are eligible to participate in the program. Antler welcomes teams from established companies to join and develop solutions. The equity allocation is based on a global standard where Antler offers a 250K investment and takes a nine per cent equity stake. However, participants have the flexibility to decide whether they want to accept the equity-free grant or not. This applies to both early-stage startups and more established companies participating in the program.
Q8: Is our approach of digitising cash logs by providing voice input and extracting text with automatic verification, vernacular support, and PDF upload capabilities correct?
A: Yes, it seems like you're on the right path. Please fill in the presentation link on the dashboard, and we will review your work and get back to you.
Q9: Can a user upload data in PDF or CSV formats to the item catalogue for automatic extraction, categorization, and template creation?
A: Yes, users can upload data in PDF or CSV formats to the item catalogue, and the system can automatically extract, categorise, and create templates based on the uploaded data.
Q10: What is the process for submitting our solution, and where can we find the presentation link?
A: To submit your solution, log into the dashboard on the website. You should find the presentation link there. If you have any trouble, please check your registration details or contact support for assistance.
Q11: Is it possible for a fintech startup that has already raised funds in an initial round to participate in the program? How does the equity allocation work in such cases?
A: Yes, fintech startups that have already raised funds in an initial round are eligible to participate. The equity allocation is based on a global standard where Antler offers a 250K investment and takes a nine per cent equity stake. However, participants have the flexibility to decide whether they want to accept the equity-free grant or not. This applies to both early-stage startups and more established companies participating in the program.
Q12: What is the expectation for the output of the competition? Are you looking for just data updates or also a prototype?
A: While a prototype is not mandatory, submitting a deck is the minimum requirement. Starting with the deck is recommended, and if you choose to work on a prototype, it's welcomed. The submission process involves three steps, beginning with the deck.
Q13: In the deck, what are the top three things you will be looking at?
A: The weightage is mostly equal across various aspects, but a significant focus is on research and insights. Emphasise the research conducted to understand the problem statement and derive the market size. Additionally, highlight your solution approach and the feasibility of the model. These aspects, along with information about your team, are crucial in the evaluation process.
Q14: What is the weight of the execution capability of the team? If I have a good product but lack experience in execution, will there be assistance, or should I bring business expertise to build a product?
A: While experience in execution is valued, Antler looks primarily at passion, need, and solution quality. The emphasis is on your determination and commitment to the venture. Antler will offer assistance, but the key factors include your drive, team understanding of the market, and agility. Bringing business expertise can complement the venture.
Q15: Can Antler India consider founders without extensive professional experience or significant achievements?
A: Yes, Antler India considers founders with various backgrounds, including those who may not have extensive professional experience or significant achievements. The focus is on qualities such as hustle, team understanding, and speed, reflecting a broader perspective on evaluating potential startups.
Q16: Should I present my healthcare product under the context of the medical sector, or should I present it as a solution applicable across different sectors, including groceries?
A: You can start by presenting your healthcare product in the context of the medical sector. However, be prepared to address how your solution can scale to other sectors, such as groceries. Antler is interested in versatility and scalability.
Q17: On the ondc platform, we are not providing any discounts currently. How should we plan to scale given that other platforms offer deep discounting? Is discounting applicable on ondc as well?
A: The question of discounting may not be immediately relevant for this stage. Focus on presenting your product and its value proposition first. Discussions about pricing, including discounting strategies, can be addressed in subsequent stages of evaluation.
Q18: On the dashboard, I found a form and a submit button. Is that the final submission, or do I need to submit artefacts on the next page?
A: The submission process occurs on the dashboard itself. You need to fill in the required fields and upload the necessary artefacts using the provided template. The submission and artefact upload are part of the same process on the dashboard.
Q19: If I submit before the deadline, can I update my submission in the meantime?
A: Yes, you can update your submission multiple times before the deadline. Simply click on the same submit button, and it will append the previous solution with the latest updates.
Q20: My startup is involved in order and inventory management for services, not for groceries. Am I still eligible to apply for the order management and inventory management problem statement?
A: The focus of the problem statement is on order and inventory management, and it is not limited to a specific industry. If your startup is working on order and inventory management for services, you are still eligible to apply for this problem statement.
Q21: I am currently working on the reverse logistics problem. As a master's student from NIT Trichy with a startup that has been registered but not yet live, are we eligible to participate in this program?
A: Yes, you are eligible to participate. However, please carefully consider the commitment required, as participation in the program may involve serious dedication and decision-making, including potential decisions about leaving your current academic path. This is a significant opportunity, and you should make a thoughtful decision based on your commitment to the cause and the potential impact of your solution.
Q22: My startup is involved in order and inventory management for services, not for groceries. Am I still eligible to apply for the order management and inventory management problem statement?
A: The focus of the problem statement is on order and inventory management, and it is not limited to a specific industry. If your startup is working on order and inventory management for services, you are still eligible to apply for this problem statement.
Q23: I want to confirm whether building the solution is exclusively for online commerce or also includes Kirana stores in the context of Ondc. Additionally, is there support from Google Cloud resources for building the POC, and if I don't plan to start a company, can I still submit a solution for the deck? Lastly, for the impact numbers collected, what level of accuracy is expected for the solution?
A: The solution is not limited to online commerce; it also applies to Kirana stores. Yes, there is support from Google Cloud resources for building the POC. However, if you do not plan to start a company, you may not receive the grant or support. For impact numbers, while accuracy is important, we understand that it may not be perfect. Do your best to provide reliable and realistic estimates based on the information available.
Q24: We are developing a data-as-a-service platform for OndC. In the next six months, we anticipate legal checks related to data encryption and privacy. Is there a specific jurisdiction or regulatory body, such as the DPDP Act, responsible for ensuring data security within the OndC framework?
A: OndC, being the name of the protocol, does not have a specific regulatory body associated with it. The responsibility for data security and privacy compliance may lie with existing data protection regulations and authorities. Ensure that your platform adheres to relevant data protection laws and guidelines in the jurisdictions where it operates. If there are any specific OndC-related regulations, they would be communicated by the OndC organisation.
Q25: In the context of personalised experiences, does it also consider factors like usability, especially for individuals with visual impairments or those who speak vernacular languages?
A: Yes, the concept of personalised experiences should encompass usability considerations, including addressing the needs of individuals with visual impairments and those who communicate in vernacular languages. Exploring and implementing solutions that cater to diverse user requirements is encouraged within the framework of building a data-as-a-service platform for Ondc.
Q1: Can we obtain a dataset for training the model?
A1: Certainly. Our ecosystem is open source, and all our models are available as such. You can visit the ONDC website, particularly the Olga section, to explore various datasets relevant to different use cases. The key is to align the chosen dataset with your specific use case and leverage it for developing your MVP. Yes, these datasets are openly accessible, covering diverse industry domains.
Q2: Should we use a particular tech stack, or can we choose it on our own?
A2: We offer flexibility in choosing the tech stack for your project. Our ecosystem is open source, and the integration can be based on the familiarity and skills of your development team. We are technology agnostic, and our APIs are based on restful principles, allowing you to choose a tech stack that aligns with your preferences and expertise, whether it's open or closed source
.
Q3: Can Python with Flask or FastAPI be used for the project?
A3: Absolutely. The choice between Flask and FastAPI depends on how you plan to address the problem statement. The flexibility allows you to develop either a web application or a mobile application with support for Indic languages. If you opt for a web application using Python, Flask is a suitable choice. The decision between Flask and FastAPI can be based on your specific project requirements and preferences for development.
Q4: What is the minimum number of Indian Regional languages proposed for MVP support?
A4: While the problem statement does not specify a fixed number of languages, it is recommended to consider two or three languages, including English, for an MVP. Given that Bhagini provides support for 22 Indic languages, choosing two additional regional languages along with English would be a practical approach for an MVP. The emphasis is on selecting languages that cater to the evaluator's understanding and effectively showcase the solution's capabilities.
Q5: Should we focus on testing the accuracy of transcription and OCR in the MVP?
A5: While preparing the MVP, it is advisable to prioritise showcasing the functionality rather than focusing solely on accuracy. The emphasis should be on demonstrating how the solution works, especially in terms of retrieving data and presenting translations. Evaluators are generally more interested in understanding the functionality, and accuracy can be addressed gradually. Bhagini may have benchmarks for accuracy, but it is not the primary concern at the MVP stage. If any issues or challenges related to accuracy arise, participants are encouraged to report them for further guidance.
Q6: Is it acceptable to use Python libraries like Gradio for constructing the MVP user interface?
A6: Yes, it is acceptable and recommended to use Python libraries like Gradio for constructing the MVP user interface. These libraries are considered low-code frameworks that facilitate rapid web development and interactive UI with ML model support. Leveraging such libraries can expedite the MVP development process, allowing participants to allocate more time and attention to the development of core components.
Q7: Do we have to create an API that can translate images as well?
A7: Yes, the problem statement mentions the extraction of content from text images. To achieve this, participants can utilise OCR capabilities, and Bhavani provides OCR APIs for this purpose. Participants have the flexibility to choose libraries or tools, such as Tesseract or others, based on their preferences and capabilities, as the problem statement does not limit the choice to a specific library. The goal is to demonstrate the capability of extracting content from text images in the MVP.
Q8: I am exploring technologies for handling different input types. Are there any preferred frameworks or tools you would recommend for processing both voice and image inputs alongside text?
A8: Bhavani provides flexibility in choosing frameworks and tools based on the project requirements. For handling different input types like voice and image alongside text, developers can explore various frameworks such as Ruby on Rails, Python-based frameworks, or any other tools that align with their expertise. Bhavani's APIs are RESTful, ensuring that there are no platform-level dependencies. The choice of frameworks and tools is left to the discretion of the development team based on their comfort and project needs.
Q9: For voice input, accuracy is crucial. Any insights on optimising voice recognition models for Indian languages to ensure a high level of accuracy?
A9: Bhavani provides Automatic Speech Recognition (ASR) through its APIs for voice recognition. Developers can utilise the ASR API to enhance voice detection accuracy for Indian languages. Bhavani's APIs offer a dedicated Postman collection for exploration and testing. Users can test the accuracy by employing the API and providing feedback on any words or sentences not accurately recognized. The accuracy can be evaluated by using the API in real-world scenarios, and users are encouraged to share their experiences and insights with Bhavani.
Q10: Can you please explain the transaction between the seller and the buyer on ONDC and how Bhavani fits into the product?
A10: In the context of ONDC, the transaction between the seller and the buyer involves various features provided by Bhavani. Bhavani functions as a layer of translation, leveraging its capabilities in automatic speech recognition (ASR) and machine translation. The voice aspect comes into play, particularly in inventory search or translating the entire app into different languages. Wherever features such as ASR and machine translation are found in the ONDC ecosystem, Bhavani plays a role in facilitating and enhancing these functionalities.
Q11: Do we need to use any ONDC-related components for this problem statement?
A11: No, it is not a requirement. While you have the option to incorporate ONDC-related components, it is not mandatory to solve the problem statement.
Q12: If our team plans to create an AI chatbox and it takes more time, should we provide ideas and solutions for the problem in the PBT submission or wait to submit the programming?
A12: In this case, we have taken a clear stance that no documents, PDFs, or PPTs will be allowed. We are looking for an actual working application. Therefore, please focus on submitting the actual programming and implementation rather than ideas or solutions in the PBT submission.
Q13: Can we attach a PDF in the Gator and send it to you?
A13: No, it should be a workable solution, and the evaluation will assess how good the solution is in practice.
Q14: What laptop is best for interfacing with Dialog Flow and Bootpress.com? Any technical advice to make the project beneficial?
A14: Please feel free to use any platform or tool that you think will help provide a better solution. There's no specific requirement, and it can be an open-source or cost-effective product that enhances your project. We are open to various options.
Q15: Can you elaborate on the judging criteria and the tech evaluation for the conversation interface problem statement? What kind of product is expected, and are there specific scalability requirements?
A15: We are open regarding non-functional requirements and evaluation criteria. The broader evaluation constructs include extendability to other use cases, usability in terms of APIs, algorithms, and data, scalability to handle population scale with optimal capacity and minimal latency, and security ensuring transactional guarantees. Additionally, we are looking for a modular architecture with flexible integration options and open endpoints for API integration. The solution should be consistent in its application across different scenarios.
Q16: Can we add custom routes for integrating with people tsp, apart from the preferred routes?
A16: Yes, you can.
Q17: Should we close ONDC and try keeping the back BTP and TST throughout the OMC?
A17: Not required. If you want to leverage that, it's fine to enhance your solutions. However, it is not a mandatory requirement.
Q18: Should we create a technology so providers that can be integrated with ONDC in our product, or if not, can we shed more light on what exactly should be done?
A18: It can be either way. You can use our reference app, the source code of which is available on GitHub, to integrate your solutions. Alternatively, you can create your buyer application and showcase your solution on that platform. Either way is acceptable, but it should ensure passing the technical evaluation criteria and meeting the requirements stated in the problem.
Q19: When creating the UI, should we make the whole UI incredible or just basic UI elements?
A19: It's up to you. The problem statement allows for creative freedom, and incorporating newer, innovative ideas will likely earn you more points.
Q20: Can you elaborate more on the judging criteria, especially the four points like capabilities, security, etc.?
A20: Certainly. The judging criteria are based on four key aspects:
Usability: Evaluation of APIs, algorithms, and datasets on which the solution is built.
Extendability: The solution should be extendable to other use cases and not limited to a specific domain.
Scalability: The solution needs to be scalable to handle a large user base effectively.
Security: Assessment of the security measures implemented in the solution.
These are the primary technical criteria against which the evaluation of the solutions will be conducted.
Q21: For the emergency experience in fashion shopping, are there specific technologies or approaches we should consider to provide a realistic tryout feel for the users?
A21: In this context, we are not experts in that area. We encourage participants to explore and propose suitable technologies or approaches that can enhance the emergency experience in fashion shopping. The goal is to provide a realistic tryout feel for users, and we are open to innovative solutions in this regard.
Q22: What should be the final product? Should I develop a demo website with only functionalities related to the children's topic?
A22: Yes, for the initial submission, creating a prototype or demo website focused on functionalities related to the children's topic is recommended. This will allow you to effectively demonstrate and explain your idea to mentors and judges. Ensure that the prototype provides a clear representation of your concept, making it understandable and compelling for the evaluation process.
Q23: What is expected in PDF solutions? Should I provide a concise overview of our approach, or is it required to include a comprehensive document covering all aspects of the solutions?
A23: Based on the topics or challenges selected for the next Ventures or hackathon, you will be provided with a sample PPT that requires basic details related to those specific problems. On your dashboard, you will find templates corresponding to these challenges. Ensure to address all the topics listed in the provided PPT to effectively convey your approach and solution comprehensively. Follow the guidelines and provide the necessary details to help mentors and judges understand your idea.
Q24: Can the same team members create another team and submit solutions for the problem statement?
A24: For multiple submissions, each team member needs to create a separate ID, as one person cannot be part of multiple team IDs. It is not encouraged to create multiple teams with the same members for a single problem statement.
Q25: What do I need to upload and make in GitHub for the project?
A25: On GitHub, you should upload all the resources, code structure, and any files related to your prototype or project. Include detailed documentation with steps to set up and run your project, such as required packages, environment variables, and installation instructions. You can also use markdown files (`.md`) to provide additional details. GitHub supports various formats, and there are no specific limitations on the type of information you can include. You can go all out in explaining and documenting your project on GitHub.
Q26: Considering potential connectivity issues, should the solution have any offline capabilities for language support, or is it assumed that the user will always have an internet connection?
A26: It's a good practice to consider potential connectivity issues, especially in rural or low-connectivity areas. You can implement offline capabilities in your solution by allowing users to download essential data when they have an internet connection. This downloaded data can then be used offline when connectivity is not available. You may also provide a notification or message to users, informing them about the need to connect for specific features or updated content. Examples from other industries, like offline transactions on flights, can inspire creative solutions to address this challenge.
Q27: Are there any plans to incorporate community-driven features, such as user-generated translations or specific forums, to enhance the language support ecosystem?
A27: While the idea of community-driven features like user-generated translations and specific forums is not explicitly mentioned in the problem statement, it is encouraged to explore innovative solutions. If you have creative ideas around adaptive language support that evolves through user feedback and interactions, feel free to propose such solutions. The emphasis is on encouraging innovative approaches, so you can explore new features that enhance the language support ecosystem.
Q28: What is the ideal submission for the Data as a Service problem statement?
A28: For the Data as a Service problem statement, please follow the guidelines provided in the specific problem statement. Make sure to address all aspects mentioned in the template or guidelines provided on the dashboard. If you have any specific questions related to this problem statement, feel free to ask.
Q29: Are there any regulatory challenges when using voice recognition, especially in the medical sector, where mispronunciations of medicine names might occur?
A29: The team acknowledges that mispronunciations of medicine names can be a challenge. Currently, there is no glossary of medicines provided, and building your glossary and model is necessary. The team emphasises the importance of addressing this issue in the solution and suggests starting with basic medicine names for the MVP. They mention that the ONDC medical sector is not supported, but you can still work on the medical sector from the ONDC side. Additionally, they advise considering compliance issues related to mispronunciations or spelling errors in the solution.
Q30: Can we restrict ourselves to specific categories like electronics and fashion for developing a prototype, considering the vastness of the ONDC catalogue?
A30: Absolutely, you can start with a small category or even a subcategory within electronics or fashion. The key is to create a scalable prototype that can be extended to more use cases. Focus on demonstrating your solution effectively within the defined segment.
Q31: Regarding compliance, in the case of commerce compliance laws in India, which are limited, would adhering to SSA laws be sufficient, especially when dealing with electronic products?
A31: The response indicates that the compliance question is ambiguous, seeking clarification on whether it pertains to the compliance problem statement. The suggestion is to approach mentors from the specific problem statements to get more accurate answers.
Q32: Is the expectation that whatever is submitted as a solution on January 15th will be what is demoed on Demo Day in February or March?
A32: Yes, the expectation is that whatever is submitted as a solution by January 15th will be demoed on Demo Day. However, there will be a few days between the final shortlist and Demo Day to further develop the product.
Q33: In the cohort, if only the winners are selected (2 or 3), do they join the cohort, or are there multiple openings for participants?
A33: For cohort-related queries, participants are advised to email their questions to support@hack2skill.com to receive more detailed information.
Q34: Can any team member submit the idea or only the team leader is allowed to submit it?
A34: Any team member can submit the idea; it is not restricted to the team leader. Each team needs to submit their idea only once.
Q35: How will other commerce applications benefit from the ONDC Unified Logistics Interface?
A35: Please attend other committee calls where ONDC is discussing business and technical details. They will provide information on how other commerce applications can benefit from the ONDC Unified Logistics Interface.
Q36: I registered in Data as a Service and uploaded the document, but when I downloaded the link, the presentation interview did not take the problem statements. What should I do?
A36: In the dashboard, go to the "Submission" tab. Click on it, and there you will find the option to submit your presentation. Make sure to submit your presentation through that section.
Q37: In the Next Gen Venture section, you mentioned to apply. Can only registered startups apply?
A37: Yes, only registered startups can apply. For further details, please attend the relevant session or reach out via email at support@hack2skill.com.
Q38: For the translation task, is it better to use pre-trained models or APIs? Will training a specific model be more beneficial?
A38: The suggestion is to start by using APIs to check if the translation works for the specific use case mentioned in the problem statement. In general, there is no need for additional pre-training. The recommendation is to use the APIs and provide feedback.
Q39: Is Bharti mandatory for the Indic Language Support problem statement, or can other models be used for text-to-speech and vice versa?
A39: While there are many options available, Bharti is recommended for accuracy since it's specifically designed for Indian languages. However, using other open-source models is acceptable based on the team's comfort. For the demonstration, the MVP and POC should include English and two regional languages. As for image support, the focus is on extracting text content from images. If a user uploads an image containing text, the goal is to extract the text content and OCR APIs.
Q40: Is there any cost associated with using the provided APIs like Bharati?
A40: Currently, there are no charges associated with using the APIs. Teams can utilise them freely to build their MVPs and POCs.
Q1: What are the primary data sources used to inform pricing recommendations in ONDC?
A1: The primary data source for pricing recommendations in ONDC is network data, which includes order data, product selection data, and other information derived from buyer and seller applications. The National Health monitoring logs submitted by each buyer and seller application provide valuable insights into product searches, selections, additions to cart, and orders.
Q2: Could you provide a brief explanation of how ONDC works in terms of buyer and seller applications and the communication process between them?
A2: ONDC involves two network participants – buyer applications (consumer-facing apps) and seller applications (merchant apps). Buyers use the buyer app to search for and discover products, add them to the cart, place orders, and make payments. Sellers use the seller app to list their products, which are accessible to all buyer applications. The communication process includes search, select, init (pre-reservation), and confirmation calls between buyer and seller apps to ensure product availability, reserve items, and confirm payments before order fulfilment. The entire process facilitates seamless interactions between buyers and sellers on the ONDC platform.
Q3: What are the key data points available in ONDC, and how can they inform pricing recommendations?
A3: ONDC provides valuable data points such as search calls, select calls, init calls, and confirm calls between buyer and seller applications. These calls offer insights into product availability, user behaviour, and pricing. Network data, submitted to the National Health monitoring system, includes information on product searches, add-to-cart behaviour, and actual order behaviour. Utilising these data points, one can analyse product pricing, user interactions, and market trends for effective pricing recommendations.
Q4: How does identifying unique products based on standard classification, such as EAN codes, enhance the accuracy of the pricing engine?
A4: Identifying unique products through standard classification, like EAN codes, is crucial for the accuracy of the pricing engine. For instance, different varieties of mangoes may have distinct prices. If the pricing engine can differentiate between mango varieties, such as Alfonso, Langda, and Kesar, it can provide more accurate recommendations. Treating all mangoes as the same product might lead to incorrect pricing suggestions, emphasising the importance of classifying products accurately for precise pricing insights.
Q5: How can a seller determine the optimal price for products on ONDC?
A5: Sellers can approach pricing decisions by considering factors like cost, margin expectations, and marketplace dynamics. They can experiment with different discount levels, starting from their existing offline store prices. Running A/B tests helps discover the optimal price point that balances demand and profit margins. Sellers can define minimum and maximum prices and continuously test to find the most effective pricing strategy based on their unique circumstances.
Q6: What are the key factors influencing pricing decisions on ONDC?
A6: Pricing decisions on ONDC are influenced by factors such as cost, margin expectations, demand, and inventory levels. Sellers need to step into the buyer's and seller's shoes, considering whether to set prices based on cost, competition, or a combination. Inventory velocity, influenced by factors like weekdays or weekends, also plays a role. Sellers may need to experiment with different discount levels and understand the impact of factors like brand recognition and product specialisation on pricing strategies.
Q7: How does the application consider consumer demand, production, and inventory levels simultaneously in pricing decisions?
A7: The application considers consumer demand, production, and inventory levels by analysing data available on the platform. Sellers can run experiments to discover the right price point by experimenting with different discount levels and observing buyer behaviour. Inventory velocity, influenced by factors like weekdays or weekends, also plays a role. Additionally, brand recognition and product specialisation impact how listings are ranked, making it essential for sellers to continuously test and refine their pricing strategies.
Q8: How does the concept of time range validity of prices work in ONDC, considering factors like perishable goods and demand patterns?
The time range validity of prices on ONDC is influenced by factors such as supply and demand dynamics, especially in perishable goods. Sellers can identify specific time windows with high demand, like lunch or evening snacks, and adjust prices accordingly. For perishable goods nearing expiration, a seller might choose to offer stronger discounts to ensure quick sales. The internal time frame is complemented by market-driven time frames, where sellers aim to be the best in identified patterns, enhancing sales during peak windows.
Q9: What specific artefacts, data models, algorithms, etc., should be considered when computing prices on ONDC?
A9: The choice of artefacts, data models, and algorithms for computing prices on ONDC is not prescriptive, and it depends on the specific context and requirements of each seller. Sellers are encouraged to explore and identify the most suitable models for their pricing strategies. The flexibility allows for creative and effective solutions tailored to individual needs.
Q10: How should applications demonstrate their ability to dynamically change prices, considering variables and specific scenarios?
A10: Applications should demonstrate the ability to dynamically change prices through simulations based on historical order data. Sellers can showcase their models' capabilities to identify patterns and adjust prices accordingly. The demonstration should include controls, such as min-max price ranges, velocity controls, and the option for sellers to choose their position in the market. Additionally, providing predictive demand insights, both automatically and manually, and presenting reports on A/B test results can enhance the demonstration.
Q11: Can you elaborate on the controls that can be implemented for sellers, such as min-max price ranges, velocity controls, and positioning in the market?
A11: Sellers can be provided with controls like min-max price ranges, allowing them to define acceptable price limits. Velocity controls enable sellers to manage the speed at which their inventory is sold, adapting to factors like perishable goods or supply constraints. Sellers may also choose their position in the market, deciding whether to be the best-priced or accept a lower ranking. These controls empower sellers to tailor their pricing strategies to specific needs and market conditions.
Q12: Are there specific security measures or compliance requirements for handling pricing data on ONDC?
A12: The pricing data on ONDC is not considered sensitive, as it does not include personally identifiable information. While handling pricing data, sellers should avoid exposing non-public information and ensure that competitive intelligence is aggregated to prevent individual identification. Protecting against misuse and reflecting competitive information responsibly is crucial.
Q13: What opportunities for testing solutions are available during the hackathon, especially concerning real-world scenarios?
A13:Participants can leverage historical data for testing solutions during the hackathon. Additionally, they may collaborate with seller applications or setups to identify willing sellers for real-world testing. Using a simulated dataset or partnering with sellers who agree to experimentation can provide valuable opportunities for testing and refining pricing solutions.
Q14: How should sellers interact with the system to receive pricing recommendations and make informed decisions?
A14:Sellers can interact with the system through a control panel where they receive insights into market pricing, recommended changes, and the impact on potential sales. The system should provide controls such as Min-Max pricing, allowing sellers to set their position in the market percentile. Additionally, reports detailing past experiments and their outcomes can aid sellers in making informed decisions.
Q15: What considerations should sellers keep in mind to avoid pricing practices that may resemble dumping products in the market?
A15: Sellers should ensure there is a minimum price in place to prevent aggressive pricing practices that resemble dumping products in the market. This minimum price should be set responsibly to maintain fair competition and market stability. This practice aligns with ethical pricing strategies and contributes to a balanced marketplace.
Q16: Can you provide examples of price optimization implementation in industries, similar to how the system might function in this context?
A16: Examples include airline ticket pricing, where dynamic changes are made based on factors like inventory, competitor pricing, and consumer behaviour. Similarly, the advertising industry, such as Google Ads, leverages dynamic pricing strategies by predicting impressions and clicks based on bid adjustments and competition.
Q17: Are there specific ethical considerations for participants when designing algorithms for price optimization in diverse markets?
A17: Participants should avoid dumping products or exposing data at a merchant level. Ethical considerations primarily revolve around responsible pricing practices and avoiding actions that could harm fair competition or violate legal standards.
Q18: How does machine learning contribute to the decision-making process of price optimization, and how can participants effectively leverage ML techniques?
A18: Machine learning helps optimise pricing by handling a multitude of variables and identifying essential factors. Participants can leverage ML techniques to analyse large datasets, identify key variables impacting pricing, and enhance the accuracy and efficiency of their pricing models.
Q19: How does the system handle external factors, such as economic changes or unforeseen events, impacting pricing strategies?
A19: The system can either embed predictability around economic changes or use signals to identify events. Sellers can adjust pricing based on known events, and the system can be equipped with alerts to detect significant shifts in market prices, triggering adjustments in response to unexpected events or changing market conditions.
Q20: How can participants address potential challenges related to the credibility of pricing models for stakeholders and end-users?
A20: Participants should focus on creating a credible pricing model in the first place. The credibility of the model depends on its accuracy, reliability, and ability to effectively optimise prices based on relevant factors.
Q21: Are there specific guidelines for incorporating discounts or promotional offers into pricing strategies, and how can they be balanced with profit goals?
A21: Sellers should set controls, specifying the acceptable price range for dynamic changes. Sellers need to establish limits to ensure that prices don't go below certain points, protecting profit margins. It's essential to balance promotional offers with profit goals and communicate these guidelines to sellers.
Q22: How will the solutions be judged? Will it involve live servers, A/B testing, or other methodologies?
A22: The judgement of solutions will likely consider a holistic approach. A good solution should include both an improved algorithm for maximum profit and a user-friendly dashboard with controls for sellers. The evaluation may involve live server testing, A/B testing, or other methodologies to ensure the effectiveness of the solution in real-world scenarios.
Q23: How does the system manage the challenge of buyers seeing products at different prices from various sellers, impacting logistical efficiency?
A23: The challenge arises when buyers see products at different prices from different sellers, impacting logistical efficiency. One potential solution is to allow buyers to optimise their cart later, consolidating products from different sellers into a single order, and promoting local retailers to come on board.
Q24: What measures are in place to ensure the credibility of the pricing models and the balance between algorithmic optimization and manual seller controls?
A24: The system should ensure that the pricing model is credible, accurate, and reliable. It should strike a balance between algorithmic optimization and manual seller controls. Sellers should have the ability to set controls, specifying acceptable price ranges and ensuring that prices don't erode profit margins.
Q25: How should participants address the issue of credibility in pricing models to ensure trust from stakeholders and end-users?
A25: Participants should focus on building a pricing model that is accurate, reliable, and able to optimise prices effectively. Transparent communication and a user-friendly interface can help build trust among stakeholders and end-users.
Q26: Are there specific considerations for balancing discounts or promotional offers with profit goals, and how can participants incorporate these into pricing strategies?
A26: Participants should establish controls for sellers to define acceptable price ranges, ensuring that discounts or promotional offers align with profit goals. Striking a balance between promotional activities and maintaining profit margins is crucial for sustainable pricing strategies.
Q27: How will the solutions be evaluated in terms of their effectiveness, and will there be a focus on live server testing or other validation methodologies?
A27: The evaluation of solutions will likely consider both algorithmic improvements for maximum profit and the inclusion of user-friendly dashboards with seller controls. Live server testing, A/B testing, or other validation methodologies may be used to assess the real-world effectiveness of the proposed solutions.
Q28: During the final demonstration, how should participants showcase their solutions? Will there be specific guidelines provided, or should participants await further instructions?
A28: Participants should await further instructions regarding the final demonstration. Any queries related to this can be directed to email at support@hack2skill.com.
Q29: In a two-tier or three-tier city of India entering the online retail market, how can viability be evaluated considering challenges related to topography and infrastructure?
A29: Viability in different cities depends on factors like convenience, price, and assortment. In tier 2 or tier 3 cities, even if local products may not compete on price, they can excel in other dimensions like convenience. Pricing algorithms can be applied universally, but the approach may vary based on local factors.
Q30: How can we access the data related to orders and inventory stock as an ESP, considering the network won't be storing this data?
A31: The network holds data related to search, units in the cart, and other consuming actions. However, inventory stock data may not be entirely reliable. While specific details weren't provided, data available in the network can be utilised for building a solution.
Q32: Can sellers choose a particular retailer to have a popular discount model for electric or electronic products? How can brands control discounts on their products?
A32: Sellers have the authority to decide pricing and discount models. Brands communicate pricing policies to sellers, and it's the seller's responsibility to adhere to them. As a seller app, your role is to enable sellers to set prices and discounts based on their agreements with brands.
Q33: In the context of electric or electronic products, can a particular seller or retailer be chosen to have a popular discount model? How can brands ensure control over discounts?
A33: Sellers have autonomy in choosing pricing and discount models. Brands communicate their discount policies to sellers, and adherence to these policies is the seller's responsibility. As a seller app, you facilitate the implementation of seller-specific pricing strategies.
Q34: Can a brand control the discounting of its products, even allowing its team to apply discounts?
A34: Brands can communicate discount policies to sellers, instructing them on how to price products. If a brand wishes to control discounting, it can specify guidelines and expectations for sellers, including restrictions on applying discounts.
Q35: How should a pricing engine for e-commerce handle products that a brand does not want to be discounted?
A35: Pricing for products not to be discounted is the seller's prerogative. Sellers should be able to specify which products should undergo dynamic pricing and which should follow manual pricing. The pricing engine must provide flexibility to accommodate varying pricing strategies for different products.
Q36: When building a pricing engine, should it apply to all products all the time, or should sellers have discretion in choosing which products to apply the pricing engine to?
A36: The pricing engine should not be universally applicable to all products. Sellers should have discretion in choosing which products to apply dynamic pricing to and which products to manually set prices for. The engine should offer recommendations, but the final decision rests with the seller based on their preferences and business strategies.
Q1: What role can data and analytics play in optimising grocery order and inventory management within the ONDC network?
A1: Data and analytics are crucial for understanding the performance of the ONDC network. They provide insights into order processing, delivery times, and overall business dynamics. Analysing data helps identify areas for improvement, address gaps, and capitalise on successful strategies. For instance, analytics can reveal product demand at the PIN code level, aiding sellers in optimising their assortment. The open data provided by ONDC can assist sellers in strategizing and expanding their businesses based on demand patterns.
Q2: Regarding Ajitha's question on the ONDC network, should solutions be generic for all e-commerce or specific to the ONDC platform?
Solutions should be specific to the ONDC platform, addressing the given problem statements. While successful solutions can potentially be expanded to other categories or platforms, the primary focus should align with the ONDC network's objectives. The emphasis is on innovative solutions tailored to the challenges presented in the problem statements.
Q3: Should participants explore existing APIs and SDKs on the ONDC platform, or are entirely new solutions expected?
A3: Participants are encouraged to focus on new and innovative solutions rather than relying solely on existing APIs and SDKs. While leveraging existing resources may be beneficial, the goal is to discover out-of-the-box solutions to the presented problem statements. Creativity and innovation in addressing the challenges should take precedence.
Q4: Are participants expected to build solutions from scratch or can they build on top of existing apps already present on the ONDC network?
A4: Participants are advised to concentrate on building solutions from scratch, specifically targeting the identified problem statements. While existing apps on the ONDC network may provide insights, the challenge is to generate new and innovative solutions. The focus should be on addressing the unique challenges outlined in the problem statements rather than modifying or extending existing applications.
Q5: What challenges do grocery sellers face in maintaining accurate inventory records, and how can these challenges be addressed?
A5: Grocery sellers often struggle with maintaining accurate inventory records due to informal counting methods, unanticipated order cycles, and the need for a more organised approach. Online commerce introduces complexities with unpredictable order cycles, making real-time inventory updates crucial. Challenges include order cancellations, affecting seller ratings and overall efficiency. The mindset shift needed to adopt new inventory management practices is a significant aspect. Solutions should simplify the process, potentially leveraging technologies like scanning to automate inventory updates.
Q6: How can solutions address the unique requirements of perishable goods in inventory management within the ONDC network?
A6: Managing perishable goods in inventory requires a more precise and frequent approach due to their shorter shelf life. Solutions need to focus on daily or even more frequent deliveries, as seen in examples like Nature Kart. A comprehensive understanding of the perishable goods' lifecycle, coupled with efficient logistics, is crucial. Existing players specialising in perishable categories can provide insights into best practices. Solutions should aim to optimise inventory management specifically for perishables, considering their unique demands.
Q7: Can solutions for inventory management in the ONDC network be extended to non-perishable goods like fashion products?
A7: While perishable goods have specific challenges, inventory management solutions developed for the ONDC network can provide valuable insights for non-perishable goods, including fashion products. The key lies in adapting the core principles of efficient inventory management to different product categories. Demand prediction, order cycle optimization, and real-time updates can be beneficial for various product types, even if they don't share perishable characteristics.
Q8: How does the profitability of online retail stores in the fashion domain compare to grocery stores, considering the difference in predictability of demand?
Profitability in online retail depends on various factors, including the product category and demand predictability. While groceries may have more predictable demand patterns, the fashion domain offers different advantages. The profitability comparison is nuanced and depends on the efficiency of inventory management, customer demand, and operational excellence. Both domains have unique challenges, and success lies in tailoring strategies to the specific characteristics of each product category.
Q9: How can solutions ensure minimal disruption during the transition to a digital medium for grocery sellers within the ONDC network?
A9: The key to ensuring minimal disruption during the transition to a digital medium lies in creating solutions that are exceptionally user-friendly and integrate seamlessly into a seller's daily routine. Understanding the challenges and time constraints of a typical grocery store owner is crucial. Solutions should be designed to be easily adopted, requiring minimal time and effort for tasks like inventory management. Spending time observing and empathising with store owners' daily activities can provide valuable insights into creating solutions that are intuitive and least disruptive.
Q10: How can the ONDC network handle situations where multiple sellers in one area offer similar products, potentially leading to price undercutting?
A10: The ONDC network doesn't directly control or regulate pricing decisions made by individual sellers. In situations where multiple sellers offer similar products, pricing becomes a business-led decision for each seller. While price competition might occur, sellers need to optimise their strategies to avoid constant undercutting, ensuring sustainable and profitable business practices. The ONDC serves as a tool for sellers to reach a larger audience, leaving pricing decisions to the seller's discretion based on their business requirements.
Q11: Can solutions developed for the ONDC network's order management be extended to non-perishable goods like fashion products?
A11: Yes, solutions developed for order management within the ONDC network can offer insights applicable to various product categories, including non-perishable goods like fashion products. The core principles of efficient order management, demand prediction, and real-time updates can be adapted for different types of products. While the specifics may vary, the underlying strategies for optimising order processes remain relevant across diverse product domains.
Q12: What steps can be taken to address challenges in maintaining accurate inventory records for perishable goods within the ONDC network?
A12: Managing accurate inventory records for perishable goods requires a more precise and frequent approach, considering their shorter shelf life. Solutions should focus on daily or even more frequent updates, leveraging technologies for real-time tracking. Collaborating with existing players specialising in perishable categories can provide valuable insights. The emphasis should be on adapting inventory management practices to the unique demands of perishable goods, ensuring timely deliveries and minimising wastage.
Q13: How can the onboarding process for sellers be simplified to ensure independent completion?
A13: The onboarding process can be simplified by leveraging self-onboarding applications. Sellers can input their details, complete KYC requirements, and utilise tools like the Catalog as a Service to download and update their product listings, prices, and inventory. Integrating technologies like voice recognition for KYC or creating interactive and gamified onboarding experiences can enhance user engagement and make the process more intuitive. Considering the specific needs and constraints of small sellers, exploring AI-driven solutions and incorporating user-friendly interfaces can contribute to independent and seamless onboarding.
Q14: Are there any specific regulatory or compliance issues affecting the onboarding process for sellers on the ONDC network?
A14: The onboarding process involves two crucial steps—KYC completion and having a complete catalogue. Regulatory compliance mandates that sellers' KYC documentation must be complete. Additionally, to successfully onboard, sellers need to have a comprehensive catalogue of their products. The regulatory aspect focuses on ensuring that these two steps are adhered to before sellers can go live on the network.
Q15: Can sellers onboard to the ONDC network without having a GST number, especially for small Kirana and vegetable shop sellers?
A15: Yes, sellers can onboard to the ONDC network without a GST number. While GST is mandatory for sellers with sales exceeding 20 lakhs, the absence of a GST number does not hinder onboarding. Other relevant KYC documentation and details, such as bank information, can be provided for onboarding. The ONDC is actively exploring solutions to streamline the onboarding process for sellers without GST, ensuring it is user-friendly and efficient.
Q16: How can the KYC process be simplified for small sellers, particularly those who may not have a GST number?
A16: Simplifying the KYC process for small sellers involves exploring automated solutions that connect to government databases or ministries to retrieve relevant information. The aim is to make the KYC process seamless by automating data retrieval wherever possible. Additionally, incorporating voice recognition technology or creating gamified experiences can make the KYC process more engaging and less tedious for small sellers.
Q17: What insights can be provided on the current onboarding process for sellers on the ONDC network, and are there any challenges?
A17:The current onboarding process involves educating sellers through physical interventions, such as Freedom Streets, where teams explain the ONDC, its benefits, and the onboarding process. Challenges include completing KYC and having a comprehensive catalogue. Sellers need support in understanding the seller panel, order processes, and transitioning from staging to going live. Solutions should focus on user-friendly interfaces, automated KYC, and engaging onboarding experiences to address current challenges effectively.
Q18: How can the cost of digitization and store catalogue be reduced for sellers on ONDC?
A18:The cost of digitization and catalogue creation can be reduced by engaging brands and CPG companies to send their catalogues to ONDC's Catalog as a Service (CaaS). Brands can take responsibility for updating their catalogues, eliminating the need for individual sellers to create and maintain listings. Additionally, non-branded products can be addressed by third-party solutions, allowing for shared catalogues and minimising the burden on individual sellers.
Q19: Are there specific industry standards or protocols for catalogue business on ONDC?
A19: Currently, there are no specific industry standards or protocols for cataloguing on ONDC. However, ONDC follows a taxonomy defined by the platform to ensure that the information provided is authentic and clear. As the ecosystem evolves, it remains open to exploring and implementing standards that enhance the cataloguing process for all participants.
Q20: Are there specific challenges faced by different types of sellers in the ONDC onboarding process?
A20: Yes, different types of sellers face varying challenges during onboarding. Small traditional stores, especially those without digital inventory systems, may find it challenging to transition. ONDC is working on digitising such general trade stores through a new category called DGT (Digital General Trade). The challenges differ between modern trade and general trade formats, and solutions are tailored accordingly.
Q21: Does ONDC share consumer data with sellers, and is it safe from a consumer perspective?
A21: ONDC does not hold any consumer data. Buyer and seller interactions are facilitated through the seller network participant and buyer app. While necessary information like name, phone number, and address is shared for order processing and delivery, ONDC's role is to enable transactions between buyers and sellers, with no direct involvement in consumer data handling.
Q22: How can emerging technologies like AIML address challenges in ONDC?
A22: Emerging technologies like AIML hold great potential to address challenges in ONDC. As long as these technologies effectively address specific challenges, they can be valuable tools. ONDC encourages exploration and innovation in leveraging AIML to enhance user experiences, streamline processes, and overcome obstacles within the platform.
Q1: What is the significance of catalogue digitization in the context of ONDC, and what expectations are set for this problem?
A1: Catalogue digitization is crucial for ONDC as it facilitates a standardised language for products across various buyer and seller platforms. The goal is to enable seamless search, discovery, and order placement by ensuring that product information is consistent and easily accessible. The challenge lies in the varying capabilities of different seller entities, and the expectation is to develop tools and technologies that enable sellers, regardless of their sophistication level, to efficiently digitise and create catalogues for their products on the ONDC network.
Q2: What are the key challenges in catalogue digitization for sellers on ONDC?
A2: The primary challenges in catalogue digitization for sellers on ONDC include the diverse capabilities of seller entities, ranging from small artisans to large corporate entities. Ensuring that sellers of varying sophistication levels can easily and quickly digitise their catalogues is a major hurdle. Additionally, the need for speed and quality in digitization at scale poses a significant challenge.
Q3: What is the overall goal of the catalogue digitization project, and how does it aim to address the challenges?
A3: The overarching goal of the catalogue digitization project is to onboard the next million sellers on the ONDC platform. The project aims to tackle the core problem of digitising the selling skills of sellers who are not currently online. Key focus areas include the speed of digitization, ensuring it is done at scale, and maintaining high-quality digitised catalogues. The project seeks technological solutions to quickly and efficiently digitise catalogues, enabling a diverse range of sellers to participate in the digital marketplace.
Q4: How does ONDC envision leveraging technology to address the challenges of catalogue digitization and ensure speed and quality?
A4: ONDC envisions leveraging technology to rapidly digitise catalogues at scale while maintaining high quality. The focus is on developing tools and approaches that cater to sellers with varying levels of sophistication. Technologies such as barcode scanning for quick digitization of store inventory are considered. The goal is to empower sellers, including small artisans, to easily create digitised catalogues, fostering a faster and more inclusive onboarding process.
Q5: What are the key challenges faced by seller and seller apps in digitising large catalogues with diverse attributes?
A5: The challenges include:
1. Redundancy and Knowledge Loss: Different seller apps may have unique core businesses, and creating catalogues from scratch for ONDC may involve redundant efforts. There's a risk of knowledge loss due to attrition.
2. Data Transfer: Efficiently transferring data from the seller's store to their platform is a challenge. Ensuring quick digitization of newly signed-up stores is crucial for faster ONDC onboarding.
3. Speed of Onboarding: Rapidly bringing stores online is essential. The challenge is to shorten the time it takes from signing up a store to making it live on the ONDC network, especially for sales teams in the field.
4. Standardised and Non-Standardized Products: Dealing with both standardised and non-standardized products poses challenges. Capturing accurate images, ensuring correct angles, and lighting, and maintaining the genuine look and feel are crucial, particularly for non-standardized items.
5. Taxonomy Compliance: Ensuring compliance with the taxonomy for different products is important. This includes capturing the right attributes, descriptions, and other necessary information as per ONDC standards.
Q6: How does the challenge of catalogue digitization impact sellers with varying levels of sophistication, such as small artisans versus large corporate entities?
A6: The impact varies based on the sophistication level:
- Small Artisans: These sellers may lack the resources and expertise for efficient digitization. Challenges include the speed of onboarding, knowledge transfer, and maintaining catalogue quality without extensive teams.
- Large Corporate Entities: While they may have more resources, challenges still exist, including ensuring redundancy-free digitization, quick onboarding of diverse stores, and capturing standardised and non-standardized product information accurately.
Q7: What is the significance of the catalogue scoring system in the context of ONDC, and how does it contribute to improving the overall platform?
A7: Catalogue scoring is crucial for ONDC as it helps in:
-Sorting and Presentation:** It ensures the quality of catalogues and objectively measures compliance, correctness, and completeness (the three C's) for various product categories.
- Enhancing Consumer Trust: Higher catalogue scores build trust with consumers, leading to better choices, increased conversion rates, and improved overall customer experience.
- Ecosystem Improvement: Catalogue scoring information can guide ecosystem players in enhancing catalogues, fostering collaboration to improve overall catalogue quality on the network.
Q8: In the context of catalogue indexing, how does improving search results contribute to the buyer's experience on the ONDC platform?
A8: Improving search results is essential for enhancing the buyer's experience on ONDC by:
- Enabling Accurate Searches: Buyers can find the right products even with variations in spelling, language, or terminology, improving the accuracy of search results.
- Increasing Trust: Accurate search results build trust among buyers, ensuring they can quickly and reliably find the products they are looking for.
- Facilitating Variety and Diversity: Catalogue indexing allows different seller applications to showcase their products, providing buyers with a diverse range of options for the same or similar products.
Q9: What are the challenges faced by seller and seller apps in quickly digitising stores and making them live on the ONDC network?
A9: Challenges in rapid digitization and onboarding include:
- Time Constraints: Achieving quick onboarding within a few hours for newly signed-up stores is challenging, especially for sellers with limited resources.
- Knowledge Transfer: Ensuring that knowledge transfer about categorization and catalogue creation is seamless, even with the potential for attrition, presents a challenge.
- Image Quality: Capturing accurate images, angles, and lighting, particularly for non-standardized products, without compromising on image quality is crucial for the digitization process.
Q10: Are there specific requirements for indic language support in the interfaces used for catalogue presentation?
A10: Yes, there is a requirement for indic language support, especially for voice-based digitization. The system should support at least three languages to ensure inclusivity.
Q11: Are there any constraints or limitations on the technology that participants can use for catalogue digitization?
A11: No, there are no specific constraints on the technology used for catalogue digitization. However, it should not pose proprietary risks, and ease of use, especially for sellers, should be a priority.
Q12: Can you elaborate on the expected user experience for sellers while digitising a catalogue with at least a thousand SKUs?
A12: The user experience should prioritise simplicity, especially for local sellers like Kirana shops or artisans. It should be easy, supporting local languages, and possibly voice-based inputs. The process should involve capturing product images with suggestions for data entry to ensure accuracy.
Q13: What specific challenges exist in catalogue indexing for different types of catalogues, such as fashion and electronics?
A13: Catalogue indexing faces challenges due to the diverse attributes in different categories. Fashion catalogues, for example, are more complex with various attributes. The challenge includes efficient handling of structured queries, pattern matching, and identifying similar items to enhance search results.
Q14: Can you provide insight into the technology used for catalogue indexing and its various layers?
A14: Catalogue indexing involves multiple layers, including structured query processing, entity recognition, pattern matching, and identifying similar items. The technology closest to simulating real-world scenarios is embeddings. The challenge lies in efficiently handling large volumes of catalogue data and retrieving items based on buyer search criteria.
Q15: How is the catalogue communication protocol standardised, and what attributes are considered mandatory or optional?
A15: The catalogue communication protocol involves a set of standard attributes, with dynamic attributes represented as key-value pairs. Standardising involves defining a set of keys, and sellers can decide which attributes to send. There's a baseline of mandatory attributes like product name and price, but most attributes are optional. Sellers can choose to send additional attributes for better visibility and discoverability.
Q16: What is the direction for standardising the product communication protocol in ONDC?
A16:The focus is on defining a set of standard keys for attributes to avoid ambiguity. Sellers have the flexibility to decide which attributes to include, with a baseline of mandatory attributes. The goal is to support a wide range of attributes to enhance the buyer experience, especially for discerning buyers looking for specific product details.
Q17: Is catalogue indexing similar to filtering products in apps like Amazon, based on user-specified filters?
A17: Yes, catalogue indexing involves structured queries, similar to the product filtering mechanism in apps like Amazon. Users can input specific criteria, and the system retrieves relevant products.
Q18: Should indexes be pushed to the buyer app, or only the search results provided?
A18: Indexes are required on both the seller and buyer ends, but the types of indexes may differ. While sellers may request a list of items, buyers may need more refined search results. Both ends play a role in optimising the response and enhancing user experience.
Q19: How does the catalogue indexing engine contribute to improving the performance of catalogue language models?
A19: Catalogue indexing contributes to the efficiency of language models (llms) used for catalogue search. llms rely on pattern matching, entity recognition, and similarity search, all of which are optimised through a well-designed catalogue indexing engine.
Q20: Are you exploring predictive search, and how does it relate to improving product searchability?
A20: While predictive search, predicting user intent, and personalising the user experience are relevant, the primary focus currently is on efficiently retrieving data from large catalogues and supporting free text search. Personalization and predictive features are likely to be built upon a solid foundation of efficient catalogue indexing.
Q21: Is geospatial indexing necessary for catalogue scoring based on the ONDC's emphasis on Geo availability?
A21: No, geospatial indexing is not a part of catalogue scoring. The ONDC focuses on serviceability, using standard geospatial technologies. Geospatial indexing is primarily related to buyer app functionality based on the buyer's location.
Q22: Who owns the catalogue, and can third-party agencies provide scored master catalogues as a service?
A22:Sellers own the catalogues, and third-party agencies can indeed provide scored master catalogues as a service. This allows for innovation and specialisation in catalogue scoring, digitization, and indexing by different entities.
Q23: How can a minimum acceptable quality of catalogues be defined, and can there be standardised catalogues offered as a service?
A23: The minimum acceptable quality of catalogues is defined by mandatory attributes set by the ONDC network. Standardised catalogues can be offered as a service, with agencies innovating in catalogue scoring and digitization. It involves distinguishing between mandatory and optional attributes.
Q24: Are there privacy or security concerns associated with catalogue scoring?
A24: Privacy and security concerns should be avoided by focusing on non-sensitive information. Catalogue scoring primarily deals with the quality of the catalogue and should not involve business-sensitive details like pricing.
Q25: How can fairness and transparency be ensured in catalogue scoring, and can consumers influence catalogue scores?
A25: Fairness and transparency can be achieved through mechanisms like credentials and data accessibility. Consumers can play a role in catalogue scoring by reporting discrepancies. However, it's important to filter out spurious comments to maintain accuracy.
Q26: How will the effectiveness of a catalogue scoring solution be validated over time?
A26: The effectiveness of catalogue scoring will be validated as buyer applications use it for sorting and filtering criteria. Over time, the prominence of catalogues with higher scores will increase, indicating the impact and acceptance of the scoring mechanism.
Q26: Can buyer applications influence catalogue completeness and make certain fields mandatory?
A26:While buyer applications may influence catalogue completeness by defining their criteria, it should align with the ONDC's foundational requirements. The network sets mandatory fields, and buyer applications can further specify additional criteria to suit their unique needs.
Q1: What is the best approach to integrate legal compliance and product safety solutions into existing commerce platforms or systems? Are there specific deployment considerations or preferred architectures for such compliance presentation solutions?
A1: Integrating legal compliance and product safety solutions involves gathering regulatory information systematically. Technologies like language processing or LLMS can be used. The nature of the solution requires the collection and analysis of regulations from disparate sources like the India Code, regulator websites, gazettes, and court judgments. Automation of this process is crucial. Deployment considerations and preferred architectures depend on the complexity of data collection and analysis, making it a challenge for participants to solve.
Q2: How can different types of product services be categorised based on applicable regulations, and how can accuracy in assigning the correct regulations to each product be ensured?
A2: Categorizing products based on applicable regulations involves looking at general laws (e.g., Consumer Protection Act, Commerce Rules) and sector-specific laws (e.g., laws for packaged commodities, food products, and electronics). Accuracy is ensured by starting with digitised and available laws, performing Google searches, and cross-referencing information. It's crucial to understand the universe of regulations applicable to a specific product category, combining general and category-specific laws for accurate categorization.
Q3: How can information from multiple government repositories be effectively scaled up and updated for legal compliance and product safety solutions? Are there APIs available, or is web scraping the primary method?
A3: Currently, scraping is the primary method as proprietary solutions like Monopatra and LexisNexis, which collect such information, don't allow scraping. There are no APIs available for direct access to government repositories. The service model could involve different entities providing repository and engine services to avoid individual scraping.
Q4: In the context of a retail commerce platform with a normalised representation of legal and product safety requirements, how can users explore and identify specific regulations and standards for their products? Can large language models serve as legal or safety document repositories and assist?
A4: Large language models (LLMs) can be used as part of the solution to create a legal or safety document repository. However, the detailed approach to using LLMs for retrieving, storing, and analysing variable documentation is a challenge for hackathon participants to solve. The goal is to review numerous documents and provide context-specific answers to user queries.
Q5: How should legal and safety requirements on a retail commerce platform stay updated? Is it through auto-scripting new regulations or manual updates? What specific data outputs does each stage of a retail commerce platform expect from a legal and product safety compliance solution?
A5: Legal and safety requirements stay updated through constant monitoring of official sources like gazettes, regulator websites, and relevant ministries. Updates can be a combination of auto-scripting and manual efforts. Each stage of a retail commerce platform expects accurate and timely data outputs related to legal and product safety compliance to ensure adherence to regulations.
Q6: What are the expectations for a solution in the negotiation engine domain within the ONDC ecosystem? What should the solution focus on in terms of API specifications and functionalities?
A6: The expectations for a negotiation engine solution are broad, ranging from a new API specification within the ONDC protocol to a set of APIs that facilitate negotiations between buyers and sellers. The focus should be on allowing multiple permutations and combinations of attributes in API payloads, enabling iterative back-and-forth communication. The ultimate goal is a deterministic solution with a clear endpoint to avoid endless cycles of negotiation.
Q7: What are the expectations for a solution in the legal compliance and product safety domain within the ONDC ecosystem?
A7: The expectation is to address the diverse compliance requirements for different product and service categories. This involves understanding and digitising compliance burdens, and offering tools or knowledge bases for participants to identify compliance needs. For example, a tool that assists a new online grocery seller in identifying compliance burdens for themselves and their merchants.
Q8: In the context of legal compliance, how can technology be leveraged to simplify the identification of compliance burdens for new network participants?
The goal is to explore the possibility of using technologies like large language models (LLMs) and cheap computation power to create a monetizable service. This service would assist new network participants in identifying compliance burdens specific to their products or services. The tool could provide information through keyword searches or a standardised advisory knowledge base.
Q9: In the product safety domain, how can trust be maintained and a chain of trust established in an unbundled environment like ONDC?
A9: Maintaining trust in an unbundled environment involves addressing product safety concerns. The liability for product safety typically falls on the manufacturer or seller, but in ONDC's unbundled model, the challenge is ensuring trust between buyer and seller apps. Solutions could include legal technology, blockchain, or certification systems to establish and convey the provenance and quality of products. The goal is to create a mechanism that allows the buyer app to trust the safety of products sold by different merchants on the platform.
Q10: Are there any historical transaction contracts available that can be referred to for creating an AI negotiation-based engine?
A10: No, historical transaction data is not provided. If historical data on transactions is required for designing a negotiation-based engine, participants need to approach network participants who may have access to such data.
Q11: What is the need for an AI negotiation-based engine within the ONDC ecosystem, and what aspects of the contract negotiation process are considered for improvement?
A11: The need arises from the lack of a human-centric negotiation process in the ONDC Network. Currently, buyer and seller apps communicate through APIs, and there's no mechanism for the negotiation of contractual terms. The goal is to introduce mechanisms that allow buyers and sellers to negotiate aspects like commissions, delivery time, settlement terms, and other contractual terms present in the API payloads. The focus is on real-time negotiation to enhance the flexibility of the contract negotiation process.
Q12: What are some examples of contractual terms that could be subject to negotiation in the ONDC ecosystem, and how can technology be leveraged to enable real-time negotiations?
A12: Contractual terms in the ONDC ecosystem that could be subject to negotiation include commissions, delivery time, settlement window, jurisdiction for dispute resolution, aggregate liabilities, and any other term present in the API payload. Technology needs to be developed to consume these API payloads and enable real-time negotiation between the buyer and seller apps communicating through the APIs. The challenge is to build the technology that facilitates negotiation on various aspects of the contract in real time.
Q13: Are there any specific technologies or mechanisms that participants can consider for building an AI negotiation-based engine within the ONDC ecosystem?
A13:The problem statement does not prescribe specific technologies or mechanisms for building the negotiation-based engine. Participants are encouraged to explore and propose innovative solutions that enable real-time negotiations between buyer and seller apps in the ONDC ecosystem. The focus is on the flexibility to negotiate various contractual terms through the API payloads.
Q14: How does the negotiation process within the ONDC ecosystem differ from traditional business negotiations, and what challenges need to be addressed to make the negotiation process effective in real time?
A14: In the ONDC ecosystem, the negotiation process involves APIs, and there are no humans directly involved. The challenge is to introduce mechanisms that enable real-time negotiation of contractual terms through API payloads. This differs from traditional business negotiations where human interactions play a significant role. Challenges include developing technology that facilitates real-time negotiation, defining negotiation parameters, and ensuring a deterministic endpoint to the negotiation process.
Q1: Can you share data around delivery count for our location, the number of windows, the percentage of deliveries, and the type of deliveries in the ONDC system?
A1: The ONDC system, as described, does not provide specific data on delivery counts, number of windows, percentage of deliveries, or types of deliveries. However, in the broader context of logistics and delivery services, the importance of delivery time varies based on the nature of the order. For immediate delivery, typical for food orders, the expectation is completion within 30 to 45 minutes. Slotted delivery, often used for grocery orders, allows users to schedule deliveries within specific time windows, usually a few hours. There are also options like next-day delivery, which falls between hyperlocal and conventional logistics.
Efficiency for riders is measured by factors like the number of orders delivered per hour, with an ideal target of around two orders. The number of orders can vary based on the type of delivery (immediate, slotted, etc.) and whether the rider is part of a pool serving multiple brands or dedicated to a single brand. The time expectations for different stages of the delivery process, such as pickup, packing, and actual delivery, also play a crucial role in optimising the overall delivery time.
Q2: What is the role of a logistics aggregator in the ONDC system, and how does the Gateway function in multicasting search requests to logistics service providers (LSPs)?
A2: In the ONDC system, a logistics aggregator, acting as a logistics seller app on the platform, plays a key role in providing quotations in response to search requests from logistics buyers. The logistics aggregator's responsibility is to broadcast its available quotations to logistics buyers based on factors like distance, rates, and promised delivery time. The logistics aggregator, such as Shadowfax, operates as a logistics seller app and ensures that its system can efficiently respond to search requests with relevant quotations.
The Gateway's function in multicasting search requests involves broadcasting the search requests from logistics buyers to multiple logistics service providers (LSPs). The Gateway collects the responses from LSPs and returns them to the logistics buyer. Currently, Gateway's role is primarily that of a broadcaster and collector of responses, with potential future changes to make the response process peer-to-peer between logistics service providers and logistics buyers.
Q3: How does the ONDC system handle the selection of a logistics service provider (LSP) by a logistics buyer, and what guidelines exist for choosing an LSP on the ONDC network?
A3: The ONDC system does not prescribe a specific mechanism for logistics buyers to select a logistics service provider (LSP). Logistics buyers are provided with a logistics catalogue, defining parameters such as rates, to which multiple LSPs respond with their quotations. The selection of an LSP lies with the logistics buyer, and they may build algorithms or use their logic to choose an LSP based on their specific needs and requirements.
While there are no explicit guidelines within the ONDC system for choosing an LSP, the network encourages logistics buyers to make informed decisions. Logistics buyers may consider factors such as rates, promised delivery time, and other relevant parameters to choose an LSP that aligns with their business needs.
Q4: What is the importance of delivery time for different sectors in the ONDC ecosystem, and how is it typically measured or optimised for efficiency?
The importance of delivery time in the ONDC ecosystem varies based on the nature of the order and sector. For immediate deliveries, such as in the case of food orders, timely completion within 30 to 45 minutes is crucial. Slotted deliveries, common for grocery orders, allow users to schedule deliveries within specific time windows, and the efficiency is measured by delivering a higher number of orders within those time slots.
Efficiency for riders is typically measured by the number of orders delivered per hour, with an ideal target of around two orders. Optimization involves considering factors like pickup time, packing time, and actual delivery time, to minimise the overall time for the delivery process. The customer's understanding and patience for longer delivery times may vary based on the distance and nature of the order.
Q: 5 What specific technologies or systems are currently in place for hyperlocal delivery in the ONDC scenario, and can you provide details on the existing logistics infrastructure and technology stack?
A5: In the ONDC system, logistics partners utilise a combination of 17 APIs provided by ONDC to facilitate order placement, fulfilment, issue handling, and reconciliation. The key APIs include search, native, confirm, update, cancel, and tracking. The logistics infrastructure and technology stack at the logistics partner's end involves an Order Management System, serviceability checks, optimization of routes, and a rider app. These components collectively enable logistics partners to handle serviceability, assign riders, optimise delivery routes, and provide real-time tracking to logistics buyers.
Q6: Can you provide a more detailed breakdown of the current delivery costs, specifically for pickup, delivery, and insurance in the hyperlocal delivery space?
A6: In hyperlocal delivery, various factors contribute to the overall delivery costs. Pickup costs may be incurred based on the distance the rider has to travel to reach the store or restaurant. The primary focus is to maintain an earnings-per-hour metric for the rider, with a target of around 9,200 rupees per hour. Delivery costs are influenced by factors such as distance, time, and density of riders. Insurance is typically mandatory and chargeable, covering death and accident scenarios for the riders. Return scenarios and cash management, if applicable, can also contribute to additional costs.
Q7: Are there any hidden costs or factors that contribute to the overall delivery costs in hyperlocal delivery, and how are these variables managed by logistics partners?
A7: Hidden costs in hyperlocal delivery may include reverse logistics for returns and potential cash leakage issues. Reverse logistics involve additional charges for logistics partners and may include a fraction of the forward charges for returning the order. Cash management is crucial, and logistics partners need to address any potential cash leakage or ensure proper collection. Managing these variables requires proactive measures and risk mitigation strategies, especially in scenarios involving cash transactions and return logistics.
Q8: What is the existing process for handling returns in the industry, and how does it vary across different product categories?
A8: The industry's return process involves logistics service providers responsible for the pickup of returned items. Different product categories have specific specifications and quality checks, such as unique article numbers for apparel or IMEI numbers for mobiles. The rider checks these specifications during pickup, and if they match, the item is returned to the seller. Fraud or damage can occur if specifications are not properly checked or if quality checks are not performed. The reverse logistics process involves carrying the shipping label, as customers do not attach it.
Q9: Should the focus on assessing return rates be specific to certain product categories, demographics, or reasons for returns?
A9: Yes, the focus on assessing return rates should be specific to certain product categories. It's recommended to pick one or two categories to analyse and develop a robust system around them. Demographics may play a role, but public data availability is limited. It's more effective to concentrate on specific product categories and build tailored solutions.
Q10: How can the reverse logistics process be optimised to prevent fraudulent or damaged returns, especially in the absence of quality checks during pickup?
A10: To optimise the reverse logistics process and prevent fraudulent or damaged returns, a detailed system can be built around specific product categories. This system should include thorough specifications checks during pickup, considering unique identifiers like article numbers or IMEI numbers. Sellers may need to invest in quality checks or ensure that logistics service providers conduct them. The focus should be on implementing robust checks to enhance the overall efficiency of the reverse logistics process.
Q11: Are there specific challenges or common issues faced by sellers and logistics service providers in handling returns, and how can these be addressed to improve the return process?
A11: Common challenges in handling returns include insufficient specification checks leading to fraud or damaged returns. Sellers may not invest in quality checks, and logistics providers may face difficulties in implementing them. Addressing these issues requires collaborative efforts, with sellers investing in quality checks and logistics providers ensuring proper checks during pickup. Implementing technology-driven solutions for specification verification can enhance accuracy and reduce the occurrence of fraudulent or damaged returns.
Q12: How do delivery platforms like Swiggy and Zomato handle the backend cost of fuel for delivery riders?
A12: Delivery riders are responsible for bearing the backend cost of fuel for their vehicles. The earnings provided by platforms are designed to account for these costs, ensuring that riders can cover expenses related to fuel and other operational needs.
Q13: Is there a mechanism for delivery riders to earn more without having to work extensive hours, especially for those handling a significant number of deliveries?
A13: Yes, delivery platforms typically offer a gig-based scenario, allowing riders to choose the number of deliveries they want to undertake within a specific time frame. This flexibility enables riders to manage their workload and earnings more efficiently. While some riders may opt for extensive hours, the majority are not expected to work continuous shifts, and platforms aim to provide sustainable earning opportunities within reasonable hours.
Q14: Can the delivery prices paid to riders be increased to allow them to earn more without negatively impacting the overall value chain?
A14: Increasing the delivery prices paid to riders directly impacts the overall value chain. Logistics companies must strike a balance between providing competitive earnings for riders and maintaining affordability for customers. A sustainable approach involves optimizing costs within the system, ensuring that riders receive decent earnings while still meeting the expectations of both clients and customers.
Q15: How do delivery platforms manage pricing to remain competitive while maintaining a sustainable earning model for riders?
A15: Delivery platforms aim to optimise costs within the system to balance competitive pricing with sustainable earnings for riders. Any increase in rider pay would need to be carefully considered to avoid passing on excessive costs to clients or customers. Striking this balance is essential for the overall health of the logistics ecosystem and ensures that all stakeholders, including riders, receive fair compensation.
Q16: How is Ondc Network looking to integrate with logistics operators who have EV fleets, and what benefits does it bring to the overall logistics ecosystem?
A16: Ondc Network is open to integrating with logistics operators that have EV fleets. For example, Ola Logistics is one partner already integrated into the Ondc Network. EV fleets can contribute to reducing the cost of delivery per order, especially in specific clusters or cities. While EVs may not be suitable for all product categories or locations, they offer sustainability benefits and potential cost savings, aligning with the broader industry push towards environmental responsibility.
Q17: What factors determine the efficiency and feasibility of EV fleets in the logistics ecosystem, and how is Ondc Network addressing infrastructure challenges related to EV adoption?
A17:The efficiency and feasibility of EV fleets depend on factors such as the type of products being delivered, charging infrastructure, and the speed of EVs. Ondc Network is actively exploring and integrating EVs into its fleet, with around 20-30% of the fleet already transitioned to EVs. Addressing infrastructure challenges, such as charging stations and swappable batteries, is crucial for the successful adoption of EVs in the logistics ecosystem. Companies like Ondc are working on building the necessary infrastructure to support the broader adoption of EVs in the industry.
Q18: How are logistics platforms managing the trade-off between reduced logistics costs with EV fleets and meeting specific delivery time requirements, especially for different product categories?
A18: Logistics platforms, including Ondc Network, are navigating the trade-off between reduced logistics costs with EV fleets and meeting specific delivery time requirements. The impact varies across product categories, as some items require faster delivery, while others allow for more extended delivery times. The choice between conventional and EV fleets depends on factors like the urgency of delivery and customer preferences. Ongoing efforts involve deploying EVs strategically in areas where they align with delivery time expectations, sustainability goals, and cost-effectiveness.
Q1: Does the Prototype for ONDC Network Observability as a Service need to utilise data from a specific domain, or can any data sets be used to demonstrate data insights and sharing?
A1: The ONDC Network Observability Prototype is domain-agnostic, allowing the use of any data set to showcase data insights and sharing capabilities.
Q2: How will ONDC Network share data with Data as a Service (DaaS) providers? Is it through intercepting transactions or providing data through a separate endpoint?
A2: The data-sharing process with DaaS providers involves defining specifications within the solution. Network participants will share data through endpoints provided by the Data as a Service platform. The complete data life cycle, including collation, analysis, and insights, will be managed by the DaaS provider.
Q3: For the ONDC Network Observability Prototype, is the focus on creating a data dump or deriving actionable Data Insights for the identified problem statement?
A3: The emphasis is on deriving actionable Data Insights. While data collection is essential, the critical aspect lies in generating valuable insights that can contribute to the overall solution.
Q4: For the ONDC Network Observability Prototype, should the focus be on solving data issues for the entire network or a specific MD/category?
A4: The recommendation is to start by focusing on a specific category, defining the framework, processing data, and creating Data Insights for that category. The initial Prototype should address the needs of one category, and scalability across categories can be explored later.
Q5: Is a working MVP required in the submissions round for the ONDC Network Observability Prototype? What is the expected percentage ratio for prototype completeness?
A5: Yes, a working MVP is expected in the submissions round. The suggested approach is to create a prototype for a specific category, such as fashion. The prototype can be a small-scale solution, providing insights based on data catalogues and specifications. The emphasis is on showcasing the workability of the solution on the network.
Q6: In the context of decentralised lending within the financial services solution, does "decentralised" specifically refer to blockchain and cryptocurrency, or is it about the concept of decentralised lending through a P2P system?
A6: "Decentralised" in the financial services solution primarily refers to the concept of decentralised lending through a P2P system. While blockchain is commonly associated with decentralisation, the focus here is on multiple lenders and service providers contributing to the network's decentralised nature.
Q7: Are there any constraints or limitations in selecting a particular use case within the financial services solution for ONDC?
There are no specific limitations or constraints in selecting a use case within the financial services solution for ONDC. The platform is open to various proposals, and innovators can suggest solutions related to peer-to-peer lending or any other relevant use case.
Q8: Are there predefined mechanisms or protocols to address conflicts between lenders and borrowers in the decentralised lending ecosystem of ONDC?
A8: Yes, ONDC has a defined issue and grievance management system framework to handle conflicts between lenders and borrowers. The framework consists of three layers: issue, grievance, and resolution. The process enables participants to raise issues, file grievances, and achieve resolution over the ONDC Network. More details can be found on ONDC's GitHub.
Q9: Is there a suggested mechanism or alternative approach to maintaining tamper-proof records in the financial services solution, especially in areas where blockchain adoption may be challenging?
A9: The primary focus is on maintaining auditability in financial transactions over the network. While blockchain is one solution, any alternative technology that ensures a tamper-proof audit trail can be considered. The key is to guarantee transparency, traceability, and security in financial transactions, and various technologies can be explored to achieve this goal.
Q10: Are there predefined protocols for conflict resolution in the ONDC decentralised lending ecosystem?
A10: Yes, ONDC has a well-defined issue and grievance management system framework that facilitates conflict resolution between lenders and borrowers. The three-layered framework addresses issues, grievances, and resolutions within the ONDC Network.
Q11: Is there a sandbox available for testing the ONDC APIs, and how can participants access it?
A11: There is no specific sandbox available for the ONDC problem statements discussed during the event. Participants are encouraged to develop workable models using their resources and modules. The existing sandboxes are primarily related to ongoing projects and are not directly applicable to the hackathon problem statements.
Q12: Is access to the ONDC Slack Channel available, and how can participants join?
A12: There is no specific Slack Channel or sandbox related to the ONDC hackathon problem statements. Participants are advised to focus on developing their solutions using their resources. Access to a specific ONDC Slack Channel for these problem statements is not available.
Q13: For prototyping, do we need to register as a Data as a Service provider? What role do we register for on the ONDC, an Account Aggregator?
A13: Participants should register as a network participant when selected. The focus is on becoming a part of the network, not as Data as a Service provider initially.
Q14: What data can we expect from Network Participants (NPs) for the Data as a Service problem statement? Should we expect only transaction-level data or personalised data?
A14: Define specifications based on the use case, like customer profiling or segmentation. Identify data fields from the protocol's transaction-level contracts. Avoid asking for personal or sensitive data. Develop smart contracts for data shared by NPs.
Q15: As a Data Service Provider, are legal contracts needed with sellers and NPs? How do we govern data insights based on protocols?
A15: Yes, consider yourself a part of the network. Have legal contracts with sellers and NPs. Request data based on use case specifications and protocol. Develop APIs to inquire about data availability from NPs, respecting their responses and costs.
Q16: If NPS have the liberty to choose whether to share data, could it be a problem for new entrants trying to gain market insights? Will sharing data become mandatory in the future?
A16: The ONDC is working on the Open Data Initiative, collecting aggregated, anonymized information at a network level (e.g., orders for a category across districts) for meaningful insights. However, individual data sharing remains voluntary for NPS. The focus is on developing a catalogue of data that consumers can request, design their product accordingly, and derive insights from the network.
Q17:In the future, could sharing critical information become mandatory for NPS?
A17: The Open Data Initiative collects high-level aggregated data in a clean room concept. However, individual data sharing by NPS remains voluntary. The framework is designed to allow consumers to request specific data attributes through a catalogue.
Q18: As an NPS, will we need to create our APIs for those choosing our services, and will it be through NDC APIs?
A18: Yes, participants should create their APIs for their services. The live environment must adhere to protocols, but for prototyping, creating your APIs is acceptable. Participants are expected to propose solutions that align with the protocols.
Q19: In the future, could sharing critical information become mandatory for NPS?
A19: The Open Data Initiative collects high-level aggregated data in a clean room concept. However, individual data sharing by NPS remains voluntary. The framework is designed to allow consumers to request specific data attributes through a catalogue.
Q20: As an NPS, will we need to create our APIs for those choosing our services, and will it be through NDC APIs?
A20: Yes, participants should create their APIs for their services. The live environment must adhere to protocols, but for prototyping, creating your APIs is acceptable. Participants are expected to propose solutions that align with the protocols.
Q21: What criteria will be used for judging applications? How can I make my application stronger?
A21: Focus on scalability. Choose a small segment for your solution but demonstrate how it can be scaled. For example, if working on fashion, showcase how the same solution can be applied to food, green, or oil. Emphasise the potential for broader application.
Q22: Is there an existing player on the network providing a similar data service?
A22: No, there are currently no existing players providing a similar data service on the ONDC network. Participants have the opportunity to innovate in this space.
Q23: Will there be a protocol for data services, or will individual players provide different APIs and specifications?
A23: The ONDC is working on enabling data services. Participants should focus on creating API specs for their services, mapping the journey from the buyer app to the lender, and ensuring compliance with the protocols. The ONDC tech team will validate these aspects during the development process.
Q24: Is data governance and monitoring, especially compliance, the responsibility of the Data Service Provider (DSP)?
A24: Yes, as a DSP, you will be responsible for governance, compliance, and monitoring of the data. This includes the storage and management of aggregated data based on contracts with the entities providing the data. ONDC ensures that API information follows certain standards and avoids sensitive business information.
Regarding the open source maps problem, can you clarify what is expected beyond what is already provided by solutions like OSRM (Open Source Routing Machine)?
A1: Participants can explore integrating OSRM with mapping technologies like OpenStreetMap and define administrative areas for creating custom polygons. Additionally, exploring functionalities like generating multiple paths between two points, reverse geocoding, and computing motorable distances and time can enhance the solution.
Q2: How will solutions for Open Source Maps be judged? Is it based on the best algorithm implementation or the number of features implemented?
A2: Judging criteria include both the number of features implemented and the quality of their implementation. The evaluation considers how well the features are enabled on the open source map, the cleanliness of the code, abstraction quality, and ease of integration.
Q3:In the context of Open Source Maps, can ONDC provide some data on which we should work?
A3: Participants are expected to generate their data for testing. Various tools on the web can help in creating random test data. While internal data structure and storage methods are up to the participants, the input and output formats should be standardised.
Q4: Regarding the challenge name "Optimal Storage and Retrieval of Sparse Matrix," does it imply converting raw data provided by ONDC into a CSV and storing it in an optimal data structure for efficient retrieval?
A4:Participants generate their raw data. The challenge involves storing this data in an optimal data structure and ensuring efficient retrieval. While the input and output formats need standardisation, the internal data structure and mechanics are at the discretion of the participants.
Q5: What does the term "separated" mean in the problem statement for Open Source Maps?
A5: "Separated" in the context of Open Source Maps means that the definition and verification of services happen in two different places. The information is defended on one side, aggregated from multiple definitions on the other side, and then provided to access information efficiently.
Q6: Are we now supposed to submit our idea?
A6: Yes, you can proceed with your submission. Please go ahead.
Q7: When presenting a blueprint for the Open Source Maps problem, should we mention how we handle different data formats, and is it acceptable to make assumptions about data formats?
A7: Participants can make assumptions where needed, especially regarding data formats. It's acceptable to mention how you would handle different data formats, but transparency in communicating assumptions is crucial.
Q8: Can we present assumptions in the blueprint related to data formats and how data will be processed?
A8: Yes, participants can present assumptions related to data formats in their blueprints. Transparency is important, so clearly communicate any assumptions made.
Q9: In terms of presenting ideas for the Open Source Maps problem, how detailed should we be about handling different data scenarios?
A9: While presenting ideas, participants can provide details about how they would handle different data scenarios. It's beneficial to cover various possibilities and demonstrate flexibility in your solution.
Q10: Regarding the Optimal Storage problem, are we talking about optimal storage in a database or optimal storage and presentation in an in-memory representation within a data structure?
A10: Optimal storage refers to both persistent storage in a database and efficient in-memory representation within a data structure. The solution should consider efficiency in both storage and retrieval aspects.
Q11: How will the solution be evaluated? Is it based on the specific use case of pin code serviceability or the architecture and data structure used for storing and retrieving the sparse matrix?
A11: The evaluation considers both functional completeness for solving the specified problem statement and the ease of integration. It's crucial to provide a solution that not only addresses the defined problem but is also easily integrated into the ONDC ecosystem.
Q12: Are there benchmarks or standards used to justify the speed or efficiency of the data structures?
A12: There are no specific benchmarks mentioned during the discussion. Participants are encouraged to explore benchmarks on the web or provide their benchmarks for comparison against similar solutions.
Q13: Can we implement a database to make the PIN code storage solution more scalable, even though the problem statement primarily focuses on implementing a data structure?
A13: The primary focus is on implementing an efficient data structure for PIN code storage. Whether a database is needed is at the discretion of the participants. Scalability is more related to efficiently managing the sparse matrix data structure, and the choice of using a database is up to the participants.
Q14: Regarding scalability, should the solution be designed to handle all buyer and seller apps, or is it specific to individual buyer and seller interactions within the ONDC network?
A14: The solution's scalability is not required across all buyer and seller apps universally. Instead, it should efficiently handle interactions within the ONDC network, where serviceability information is transferred from sellers to buyers. It's not a centralized solution but rather involves a network of participants.
Q15: How will the output be generated in the context of open-source maps, particularly for PIN codes and polygons?
A15:The output depends on the specific features being implemented. For example, generating a motorable path between two points would involve a list of GPS coordinates in a specific sequence. For reverse geocoding, the output would be equivalent to GPS coordinates for a given address. There is no standard set of inputs, but different features may require different inputs and outputs. It is recommended to explore commercial mapping solutions and consider features mentioned in the problem statement.
Q16: Regarding open-source maps, do we need to generate specific outputs like PIN codes or polygons?
A16: The output depends on the features being implemented. For PIN codes, it could involve generating relevant data based on mapping technology. For polygons, it might include creating a set of GPS coordinates defining the polygon. Participants should explore existing mapping functionalities and consider additional features that align with the problem statement.
Q17: Does optimal storage, in the context of the problem statement, mean fastest retrieval or a combination of factors like scalability, speed, and overall architecture?
A17: Optimal storage implies a combination of factors. While speed and efficiency of retrieval are crucial, scalability, low footprint, and ease of integration are also essential. Participants should address various aspects to provide a comprehensive and optimal solution.
Q18: Should we focus solely on merchant and PIN code data, or should we also consider how the merchant data catalogue is going to be stored?
A18: The primary focus is on merchant and PIN code data. While the problem statement should be extensible, catalogue data is more complex. Participants are encouraged to focus on the efficient storage and retrieval of PIN code data and extensibility to other functionalities can be considered as an additional aspect.
Q19: If I provide a cloud-enabled solution, which cloud service provider should I use? Can I choose a different provider later if my idea gets shortlisted?
A19: Initially, for the project or MVP, use Google Cloud Platform (GCP). However, when commercialising your solution, you can choose the cloud service provider based on your preference and requirements.
Q20: Can I use a cloud service for storage and give API calls to it? Can I continue using the Google Cloud Platform if my idea is shortlisted?
A21: Yes, you can use cloud services for storage and give API calls. During the current initiative, it is recommended to use Google Cloud Platform. If your idea is shortlisted, you have the flexibility to choose the cloud service provider when deciding to commercialise your solution.
Q22: Regarding the open source maps problem, can I continue working on the Google Cloud Platform if my idea gets shortlisted, or can I choose a different provider for deployment?
A22: During the current initiative, use Google Cloud Platform for building the prototype. If your idea is shortlisted and you decide to commercialise it, you can choose the cloud service provider for deployment based on your preferences and needs.
Q23: What was mentioned about the open source maps problem statement regarding administrative areas and drawing polygons?
A23:The open source maps problem involves integrating with mapping technology like OpenStreetMap (OSM) and using features such as finding motorable distances, completing motorable paths, and drawing polygons. Administrative areas in mapping technology refer to higher-level abstractions like cities, districts, or countries, allowing efficient creation of polygons using existing mapping data and GPS coordinates.